Thanks, see it now...

Sergey

On 20/06/17 11:47, Ivar Grimstad wrote:

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 for of a BindingResult CDI bean. Which will allow the application developer to decide what should happen in that particular case.

Ivar

On Tue, Jun 20, 2017 at 12:30 PM Sergey Beryozkin <sberyozkin@...> wrote:

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 ? @NotNull is the 'message' to a the JAX-RS runtime it needs to validate, ValidateOnExecution(NONE) sends the message, no, don't validate, so hence I was curious why get the runtime deal with  ValidateOnExecution if removing @NotNull works...
Sorry I most likely have got confused....

Cheers, Sergey

On 20/06/17 10:50, Ivar Grimstad wrote:

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 handling of JAX-RS is not a great fit.

Ivar

On Tue, Jun 20, 2017 at 11:43 AM Sergey Beryozkin <sberyozkin@...> wrote:

Sorry, I was referring to @ValidateOnException...

On 20/06/17 10:41, Sergey Beryozkin wrote:

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 curiosity, what is the practical point of adding a @NotNull (and some other) BeanVal annotations and then canceling it with the other annotation ?
If the validation is not needed then wouldn't it be cleaner to remove @NotNull ?

Cheers, Sergey

 
On 20/06/17 08:34, Pavel Bucek wrote:

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 / class. But what about when

@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)

is on the resource method?

Seems like Jersey (and sorry for bringing implementation details here, but I believe it is relevant) was using @ValidateOnExecution only for deciding whether to validate return value of that method. When I fixed it, other tests are not passing and I'm not sure what should be the correct behavior in that case.

Thanks and regards,
Pavel

On 20/06/2017 07:48, Pavel Bucek wrote:

Hi Christian,

seems to be a Jersey bug.

Regards,
Pavel

On 19/06/2017 20:39, Christian Kaltepoth wrote:

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 String method( @QueryParam("q") @NotNull String query ) {

    return "Resource method was invoked!";

  }

What is the expected outcome for a request which doesn't contain any query parameter and therefore violates the @NotNull constraint?

From my understanding the use of @ValidateOnExecution disables validation and therefore the resource method must be called even if there is no query parameter in the request URL. That's how RESTEasy handles this case.

But Jersey seems to completely ignore the @ValidateOnExecution annotation in this example. Therefore Jersey validates the query parameter and returns "400 Bad Request" without invoking the resource method.

Any thoughts on this?

Christian

--

Christian Kaltepoth

Blog: http://blog.kaltepoth.de/

Twitter: http://twitter.com/chkal

GitHub: https://github.com/chkal

--

Java Champion, JCP EC/EG Member, JUG Leader

--

Java Champion, JCP EC/EG Member, JUG Leader