Validation doesn't work on OpenLiberty

[mthmulders]

Trying to build an application with Krazo on Jakarta EE 9, targeted to run on OpenLiberty. I'm using OpenLiberty 22.0.0.4, Krazo 2.0.1 (with the LibertyHttpCommunicationUnwrapper manually copied in).

The Controller that should process the form is a literal copy of the example in the MVC 2.0 spec.

I submit the form from the browser, but for convenience, this is the raw request:

curl 'http://localhost:9080/openliberty-mvc-validation/form/process' -X POST \
   -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8' \
   -H 'Accept-Language: en-GB,en;q=0.5' \
   -H 'Accept-Encoding: gzip, deflate, br' \
   -H 'Content-Type: application/x-www-form-urlencoded' \
   --data-raw 'age='

When I submit the form, I expect the Controller to be invoked, causing a) a log message to appear and b) hello.jsp to be rendered.

Instead, I get an XML response (formatted for reading convenience, the original response is unformatted):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<violationReport>
  <propertyViolations>
    <constraintType>PROPERTY</constraintType>
    <path>age</path>
    <message>must be greater than or equal to 18</message>
    <value>0</value>
  </propertyViolations>
</violationReport>

The good part is that the validation rules are applied to the input. The bad part is that the Controller is not invoked, and the user is seeing XML in their browser.

Please let me know if there's something I missed in the spec, something else I could try, or some additional information you might need.

Links:

• Reproducer project. You can start it using mvn liberty:dev.

[erdlet]

Hi @mthmulders,

I could imagine the Accept: ..., application/xml causes the trouble. Are you receiving XML even if you remove this accepted content type? It'd be weird, as you defined a q-value, but not impossible.

Also I'll have a deeper look on your example later. Thanks for providing it!

[mthmulders]

I've tried again, this time with

curl 'http://localhost:9080/openliberty-mvc-validation/form/process' -X POST \
   -H 'Accept: text/html' \
   -H 'Accept-Encoding: gzip, deflate, br' \
   -H 'Content-Type: application/x-www-form-urlencoded' \
   --data-raw 'age='

And it gives an empty response (-v shows that the response code is 400).

[erdlet]

Thanks for testing this.

I'll have a look into that.

Unfortunately RESTEasy seems to work differently on OpenLiberty than in WildFly, so I have no clue what the problem could be.

[mthmulders]

Unfortunately RESTEasy seems to work differently on OpenLiberty than in WildFly

Yes, I have noticed that before... If there's anything I could be of help with, please let me know.

[chkal]

@mthmulders What you are seeing in your reproducer project is actually the default behavior for JAX-RS when Bean Validation is provided by the runtime. In this case, requests are validated before the resource method is invoked and in case of validation errors, the request is aborted. This behavior definitely makes sense for plain JAX-RS.

As MVC requires a different behavior (controllers should always be invoked, regardless of whether a validation error occurred), Krazo has to use some "dirty" tricks. Especially, Krazo tries to veto the default CDI interceptor, which implements the behavior described above for all MVC controllers.

The interesting part of the code starts here:

https://github.com/eclipse-ee4j/krazo/blob/73ebb274f08ddb61edb10d9d4f02d66fe58478e1/core/src/main/java/org/eclipse/krazo/cdi/types/AnnotatedTypeProcessor.java#L75-L87

If removing the CDI interceptor of bean validation does not work for some reason, you will get a behavior exactly like the one you are getting. Therefore, my guess is that our code needs some more adjustments to work correctly for Open Liberty.

[mthmulders]

Thanks for the intro, @chkal. I've studied the Krazo code a bit and from what I understand, the code you've highlighted adds two annotations to existing controller methods:

1. @ValidationInterceptorBinding - should be handled by the ValidationInterceptor.
2. @AroundController - should be handled by the AroundControllerInterceptor.

The interesting thing I've observed is that for a GET request, first the ValidationInterceptor runs, and the AroundControllerInterceptor. For a POST request, none of them runs. I have added a custom validator to find a stacktrace of when the validations run - would that be of use to you?