Bug Report: JAX-RS Remapping of wrapped exceptions using a custom mapper not working anymore

[elcodedocle]

Brief Summary

Up until Payara 6.2024.1, whenever a custom JAX-RS ExceptionMapper (E.g. EJBExceptionMapper) would handle an exception (E.g. EJBException) wrapping another exception (E.g. ValidationException) mapped by another custom mapper (E.g. a custom ValidationExceptionMapper); the custom mapper (E.g. EJBExceptionMapper) would be able to:

1. Pick up that exception (E.g. EJBException)
2. Unwrap the inner one (E.g. ValidationException)
3. Have that other custom mapper handle it (E.g. a custom ValidationExceptionMapper)

This would produce the appropriate custom JAX-RS error response for that wrapped exception.

This is not the case anymore. Instead, the default mapper is selected over the custom one when requesting the mapper for the wrapped exception (E.g. via Providers.getExceptionMapper(ValidationException.class)). This results in a default error response for the wrapped exception, where the custom one was expected.

We have a reproducer on https://github.com/elcodedocle/payara-sscce/tree/payara-issue-6828:

(It is not as minimal as it could be; Please ignore the storage layer)

Running mvn clean verify on this project will deploy and run tests on the Payara version specified in the pom.xml file:

• Deploys an application with 2 endpoints that throw the same ValidationException.
  • One of these endpoints throws the ValidationException within an EJB transaction on a @Singleton EJB, so it is wrapped within an EJBException.
    • And subsequently captured by the custom EJBExceptionMapper defined on the project.
    • The custom EJBExceptionMapper will unwrap & handle the ValidationException wrapped on the EJBException, using the ValidationExceptionMapper resolved from the injected @Context through providers.getExceptionMapper((Class<Throwable>) unwrappedValidationException.getClass()) (Where unwrappedValidationException.getClass() resolves to ValidationException.class).
  • The other endpoint throws the ValidationException on the JAX-RS resource itself, so it is not wrapped.
  • The project also includes a custom ValidationExceptionMapper that should return a BAD_REQUEST 400 status response when mapping the ValidationException, for both endpoints.
• Runs integration tests for the 2 endpoints throwing exceptions.

The test for the endpoint that throws the wrapped exception will fail as described, for Payara 2024.1 and later.

The "control" test for the endpoint that throws the unwrapped exception will pass on any Payara version.

Expected Outcome

Exceptions unwrapped by custom mappers are handled by custom mappers that map them.

Current Outcome

Exceptions unwrapped by custom mappers are not captured by custom mappers that map them; a generic default error response from the default mapper is issued instead.

Reproducer

https://github.com/elcodedocle/payara-sscce/tree/payara-issue-6828

Operating System

Latest Debian 12 bookworm official Docker image

JDK Version

Latest OpenJDK 17 build from Debian 12 bookworm

Payara Distribution

Payara Server Full Profile

[elcodedocle]

( Application level workaround we are introducing until the issue is fixed, just for the custom ValidationExceptionMapper: https://github.com/elcodedocle/payara-sscce/commit/0fd3bc2fbbeadd023eef563e844243b03e36d5d2 )

[Elifzeynepedman]

Hi @elcodedocle,

I wasn't able to reproduce the error you're encountering. Could you please provide detailed steps on how to run the reproducer? This will help me ensure that I haven't missed any steps during my attempts to replicate the issue.

Thank you, Elif

[elcodedocle]

Hi Elif,

Running mvn clean verify on this project will deploy and run tests on the Payara version specified in the pom.xml file.

git clone --single-branch --branch payara-issue-6828 https://github.com/elcodedocle/payara-sscce
cd payara-sscce
mvn clean verify

Requirements:

• JDK 17 (tested on OpenJDK 17.0.12)
• Maven 3.9 (tested on 3.9.8)
• Recent Docker (tested on 27.0.3 engine bundled with 4.32.0 docker desktop for Mac)

Files of interest:

• HelloService.helloThrowEJBWrappedValidationException - Throws a ValidationException that will be wrapped within an EJBException.
• HelloResource.helloThrowNotWrapped - Throws a ValidationException that will not be wrapped within an EJBException.
• ValidationExceptionMapper - Our custom JAX-RS exception mapper overriding Payara's default ExceptionMapper @Provider for the ValidationException.
• EJBExceptionMapper - Unwraps the ValidationException from within the EJBException and calls the ValidationException mapper obtained via Providers.getExceptionMapper(ValidationException.class) to handle it.
• DeploymentIT - Runs the deployment test cases for wrapped and non-wrapped exceptions.
• pom.xml - Sets the Payara version to run the tests with.

You should be able to connect a JVM debugger to the exposed ${debug.port}, but you may have to delay execution of tests to connect before they run after the environment is deployed.

To be clear: The observed deviation is that we expect ValidationExceptionMapper to be obtained here, as it happened in previous Payara releases, but that is not the case anymore; Instead, we get the default one.

Best regards,

[elcodedocle]

Evidence from running the reproducer:

Before 6.2004.1 (E.g. Payara 6.2023.12), we get the expected com.example.payara.hello.ValidationExceptionMapper:

Since 6.2004.1, we get the default org.glassfish.jersey.server.validation.internal.ValidationExceptionMapper instead: