RESTEasy exception mapper precedence differs in JVM and native mode

[sdaschner]

Describe the bug

When introducing a general exception mapper (i.e. for Exception) with RESTEasy Classic, this results in the built-in exception mappers for WebApplicationException overriden, but only for the native mode, in JVM mode, they are still taken.

Personally, I'd be fine with either option (though I slightly prefer the WebApplicationExceptions to be handled by Quarkus), but in any case, it should behave the same in JVM and native mode.

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

Example:

@ApplicationScoped
@Path("test")
public class TestResource {

    @GET
    public String test() {
        if (new Random().nextBoolean()) throw new NotFoundException();
        return "test";
    }
}

@Provider
public class GeneralExceptionMapper implements ExceptionMapper<Exception> {

    @Override
    public Response toResponse(Exception exception) {
        exception.printStackTrace();
        return Response.status(Response.Status.INTERNAL_SERVER_ERROR)
                .header("Error", exception.getMessage() != null ? exception.getMessage() : exception.getClass())
                .build();
    }
}

In JVM mode / dev mode, the /test resource (randomly) returns a 404 error, in native mode, it returns 500 (due to our exception mapper).

Output of uname -a or ver

No response

Output of java -version

OpenJDK Runtime Environment Temurin-18.0.1+10 (build 18.0.1+10)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

3.2.0.Final

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[gsmet]

Could you assemble a simple Maven reproducer with a test that works in JVM but not in native (or the opposite if it makes more sense)? Thanks.

[sdaschner]

Sure: https://github.com/sdaschner/quarkus-playground/tree/resteasy-issue-36054

But in fact, I made a mistake, the issue only appears in dev mode vs. prod/JVM/native mode, so it only is an issue with quarkus:dev, there seems to be no difference between JVM and native (but still).

Reproduce:

mvn quarkus:dev

# different shell
mvn test-compile failsafe:integration-test failsafe:verify 
# (passes)

vs

mvn package
java -jar target/quarkus-app/quarkus-run.jar

# different shell
mvn test-compile failsafe:integration-test failsafe:verify 
# (fails)

[gsmet]

I retried the reproducer with 3.16.4 and I have a test failure in both cases so I think this has been fixed somehow.