Hi John,
I haven't drilled into this yet, but it reminds me of something which
might be relevant. I remember working on an issue, the details of which
I forget but probably related to validation, in which I was also seeing
nondeterministic behavior. In particular, sometimes I was seeing an
object in the form of a Weld proxy, and at other times the same object
was showing up as an EJB proxy. I don't remember the outcome of the
issue, but I think I never found an explanation for the behavior. Maybe
something to do with timing as the application was installed?
-Ron
On 10/27/2017 03:03 AM, John O'Hara wrote:
Thank you for your responses. If I fill you in on a bit of background
about what I have experienced, then it might help clarify the issue I
see.
Background
I am running a JEE benchmark on EAP7.1 (using resteasy 3.0.24.Final).
One of rest endpoints has a @Valid annotation on a method parameter
for a complex object.
@POST
@Path("/foo")
@Consumes(MediaType.APPLICATION_JSON)
public void addFoo(@Valid Foo bar) throws Exception {
The Foo class contains different validation annotations, such as
@NotNull, @Size, @Pattern and a custom validation annotation.
One test determines how WF/EAP handles invalid requests. When I invoke
the endpoint above I see a non-deterministic response from the app
server. If I invoke the endpoint with an invalid json object I
receive a HTTP 400 exception as expected, but if I invoke the endpoint
with a valid object, and *then* invoke the endpoint with an invalid
object I receive a HTTP 500 error.
This exception only occurs on some property validation annotations and
not all (e.g. @NotNull works as expected)
The test is being run in the context of CDI, and the HTTP 500 error is
coming from the ejb3 subsystem. The ejb3 subsystem is wrapping the
ConstraintValidationException raised by hibernate-validator.
Observations
In the call stack I capture [1], and WF thread dump [2] I can see;
1.
The test is run in the context of CDI. The HTTP 500 response code
message is caused by the ejb3 subsystem wrapping a
ConstraintValidationException raised by hibernate-validator
2.
The validator is not called in
ResourceMethodInvoker.invokeOnTarget() [3] as isValidatable is
false [4], a ResteasyViolationException is not thrown
3.
The request is validated again here [5], the validation exceptions
are not acted upon in this method call and the reflected method
(which happens to be the Foo class constructor) is called here [6]
Questions
1.
Why is ResourceMethodInvoker.isValidatable false in WF/EAP?
2.
If isValidatable is false, and validation occurs again at
MethodInjectorImpl.invoke() can we not check for validation errors
and raise the correct exception there as well?
I have a standalone test that I will clean up and push out. There are
some aspects of the test that can not be published publicly, so I need
to modify them first.
Thanks,
John
[1] - see failing_4.stack
[2] - see WF_stackTrace.out
[3] -
https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/...
[4] -
https://github.com/resteasy/Resteasy/blob/master/providers/resteasy-valid...
[5] -
https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/...
[6] -
https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/...
_______________________________________________
resteasy-dev mailing list
resteasy-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev
--
My company's smarter than your company (unless you work for Red Hat)