Experts, I know this is really late to discuss, but in fact, I doubt that it was a good decision to take WriterInterceptor out of the processing chain for SSE events. In fact, today I set up a

A target of JAX-RS 2.1 is support for Java 8. So I wonder why still idioms of the pre-8 age are used in the API implementation instead of Java 8 idioms. For example: default OutboundSseEvent

jaxrs-2_1-pfd-api.zip\javax.ws.rs-api-2.1-m09-sources.jar contains module-info.java. Is that by intention? I thought you wanted to omit that due that Java 9 not being final? -Markus

Dear experts, we'd like to announce that Proposed Final Draft was published on JCP JSR 370 page [1]. I'd like to encourage you all to review provided artifacts and let us know if you have any

2017-06-20 13:43 GMT+02:00 Pavel Bucek <pavel.bucek@...>: Yes, right. The @VOE given on the class-level could be overridden by @VOE on a specific method, though. Check out the JavaDocs of @VOE

Hi Gunnar, thanks for your response! please see inline. So (and allow me to ask a dumb question, I just need to be extra clear on this) if @ValidateOnExecution(CONSTRUCTORS) is declared on class

2017-06-20 9:34 GMT+02:00 Pavel Bucek <pavel.bucek@...>: That's right. So if Jersey still is executing the validation in this case, it seems to be a bug. Using this on a method (as opposed to

Sergey, I agree that disabling validation using @ValidateOnExecution is some kind of "special case". However, the JAX-RS spec explicitly mentions that getter methods aren't validated by default

Thanks, see it now... Sergey

Hi, We still want Bean Validation, but we don't want the JAX-RS runtime to do the validation for us as this will be handled by the MVC implementation and provided for the application developer in the

Hi Thanks for the explanation, though I'm still not sure why removing @NotNull can not achieve the same goal ? The controller method will get the control, check for null/etc ?

One use case for this is to allow for more fine-grained exception handling. As in the case of MVC 1.0 we want to allow the controller methods to be handling exceptions in the cases where the catch-all

Sorry, I was referring to @ValidateOnException...

Hi Pavel, All CXF ignores this validation completely which is probably not makes its BeanVal code very pure (I'll have a look at the code though), but just out of

Do we have BeanValidation expert here? ;) Gunnar? I believe the implementation should skip the method validation when @ValidateOnExecution(type = ExecutableType.NONE) is on the method

Hi Christian, seems to be a Jersey bug. Regards, Pavel

Hey everyone, I've a question regarding JAX-RS and @ValidateOnExecution. Please have a look at the following code: @GET @Path("/foobar") @ValidateOnExecution(type = ExecutableType.NONE) public

Yes I know that the target platform for Java EE 8 is Java SE 8, but what I talked about solely was the section about Java SE deployment of JAX-RS 2.1 spec, which does *not* say Java 8. So maybe we

JAXB dependency cannot be declared optional, that's a fact. Even if everyone from the EG would be for that, it won't be done. Reasons were already stated on this list. We are not going

Pavel, it seems you just have a different interpretation of the word "end user". At least I, as a car end user, do neither read the specification of pistons, nor does my car vendor add a note to