After some more digging, I have found that this issue occurs if the the rest endpoint is also defined as an ejb managed bean. e.g.
@Stateless
@Path("/policyholder")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class PolicyHolderEndpoint {
In this case the JaxrsInjectionTarget.inject() is only called on the first endpoint invocation, and not on subsequent calls. 

In the application the pusdo PolicyHolderEndpoint class is also a managed bean that is injected into other services as a single entry point for managing policyHolders.

Is it reasonable to expect a rest endpoint can also be defined as an ejb managed bean?

I need to look into why weld isn't injecting the JaxrsInjectionTarget, but I think that my original question still stands in this use case.  If we are running in a CDI context, we already ascertain in MethodInjectorImpl.invoke() whether there are validation exceptions by calling [1]. Can we fail at this point, rather than delegating the validation to the CDI manager and waiting for a callback? 

Thanks

[1] - https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/java/org/jboss/resteasy/core/MethodInjectorImpl.java#L119


On Fri, Oct 27, 2017 at 8:21 AM, John O'Hara <johara@redhat.com> wrote:
Ron,

I re-read your email and double checked the call to GeneralValidatorImpl.checkViolationsfromCDI().

I only see this being called once, on the first request.

I will dig some more to see why it is not being called on all requests

Thanks

John



On Fri, Oct 27, 2017 at 8:03 AM, John O'Hara <johara@redhat.com> 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


  1. The validator is not called in ResourceMethodInvoker.invokeOnTarget() [3] as isValidatable is false [4], a ResteasyViolationException is not thrown


  1. 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/java/org/jboss/resteasy/core/ResourceMethodInvoker.java#L305

[4] - https://github.com/resteasy/Resteasy/blob/master/providers/resteasy-validator-provider-11/src/main/java/org/jboss/resteasy/plugins/validation/GeneralValidatorImpl.java#L223

[5] - https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/java/org/jboss/resteasy/core/MethodInjectorImpl.java#L119

[6] - https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/java/org/jboss/resteasy/core/MethodInjectorImpl.java#L140






--

JOHN O'HARA

PRINCIPAL SOFTWARE ENGINEER

Red Hat




--

JOHN O'HARA

PRINCIPAL SOFTWARE ENGINEER

Red Hat