I do not say we should remove JAXB, I just wanted to ask because it was in the JSR 370 charter. I also do not see a big benefit of removing JAXB. The only problem I see is running JAX-RS 2.1 on Java

that depends on how the application is ran (on Java 9). If the app is on classpath, the *user* has to --add-module java.xml.bind. Nobody can do that for him. If the app is on module

Pavel, my point is that the application *user* simply does not know that he must use --add-module when running any binary application on Java 9, as the *user* has no knowledge that JAXB is used

Well.. the spec says nothing about running on Java 9, since Java 9 won't be final when JAX-RS 2.1 is released. When a user want's to run on Java 9, it is expected that he knows what

Pavel, this complete Jigsaw topic is a mess for the end user and I wonder what the OpenJDK guys wanted to reach with making JAXB optional… In reality no end user knows anything about Jigsaw (end

Markus, your description of user definitely doesn't read the spec document, javadocs, etc. So what exactly would be achieved by putting a note into the spec document? My

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

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

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

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

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

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 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

Sorry, I was referring to @ValidateOnException...

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

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 ?

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

Thanks, see it now... Sergey

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

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