Topics

JAX-RS and @ValidateOnExecution


 

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


Pavel Bucek
 

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


--


Pavel Bucek
 

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


--



Sergey Beryozkin
 

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


--




Sergey Beryozkin
 

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


--





Ivar Grimstad
 

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


--




--

Java Champion, JCP EC/EG Member, JUG Leader


Sergey Beryozkin
 

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


--




--

Java Champion, JCP EC/EG Member, JUG Leader



Ivar Grimstad
 

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


--




--

Java Champion, JCP EC/EG Member, JUG Leader


--

Java Champion, JCP EC/EG Member, JUG Leader


Sergey Beryozkin
 

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


--




--

Java Champion, JCP EC/EG Member, JUG Leader


--

Java Champion, JCP EC/EG Member, JUG Leader



 

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 according to the BV spec. Therefore the JAX-RS spec mentions that you can use @ValidateOnExecution to enable validation for such methods.


Christian

2017-06-20 12:50 GMT+02:00 Sergey Beryozkin <sberyozkin@...>:

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


--




--

Java Champion, JCP EC/EG Member, JUG Leader


--

Java Champion, JCP EC/EG Member, JUG Leader






Gunnar Morling
 

2017-06-20 9:34 GMT+02:00 Pavel Bucek <pavel.bucek@...>:
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.
That's right. So if Jersey still is executing the validation in this
case, it seems to be a bug.

But what about when

@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)

is on the resource method?
Using this on a method (as opposed to a constructor) equals to
disabling validation as the method isn't a constructor. That setting
doesn't make too much sense on a method, rather one would use
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS) on a the
class-level or within validation.xml.


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.
It definitely should validate both parameter and return value
constraints, or neither, based on the @ValidateOnExecution setting.
But there's no setting for having only method return values validated
but not their parameters.


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




Pavel Bucek
 

Hi Gunnar,

thanks for your response!

please see inline.


On 20/06/2017 13:31, Gunnar Morling via Groups.Io wrote:
2017-06-20 9:34 GMT+02:00 Pavel Bucek <pavel.bucek@...>:
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.
That's right. So if Jersey still is executing the validation in this
case, it seems to be a bug.

But what about when

@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)

is on the resource method?
Using this on a method (as opposed to a constructor) equals to
disabling validation as the method isn't a constructor. That setting
doesn't make too much sense on a method, rather one would use
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS) on a the
class-level or within validation.xml.
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 level, it enables validation ONLY for constructor and everything else shouldn't be validated?

And by constructor I mean constructor of the annotated type, not constructors of types which are instantiated during other class processing (invoking a resource method).

Thanks and regards,
Pavel

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.
It definitely should validate both parameter and return value
constraints, or neither, based on the @ValidateOnExecution setting.
But there's no setting for having only method return values validated
but not their parameters.

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




Gunnar Morling
 

2017-06-20 13:43 GMT+02:00 Pavel Bucek <pavel.bucek@...>:
Hi Gunnar,

thanks for your response!

please see inline.


On 20/06/2017 13:31, Gunnar Morling via Groups.Io wrote:

2017-06-20 9:34 GMT+02:00 Pavel Bucek <pavel.bucek@...>:

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.
That's right. So if Jersey still is executing the validation in this
case, it seems to be a bug.

But what about when

@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS)

is on the resource method?
Using this on a method (as opposed to a constructor) equals to
disabling validation as the method isn't a constructor. That setting
doesn't make too much sense on a method, rather one would use
@ValidateOnExecution(type = ExecutableType.CONSTRUCTORS) on a the
class-level or within validation.xml.

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 level, it
enables validation ONLY for constructor and everything else shouldn't be
validated?
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 for
the exact overriding rules.


And by constructor I mean constructor of the annotated type, not
constructors of types which are instantiated during other class processing
(invoking a resource method).
Yes, exactly, it only applies to this type itself, not any other types
referenced by it.


Thanks and regards,
Pavel


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.
It definitely should validate both parameter and return value
constraints, or neither, based on the @ValidateOnExecution setting.
But there's no setting for having only method return values validated
but not their parameters.

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