Java-ee: ProblemClientResponseFilter registered automatically as JAX-RS provider causes exceptions when using Resteasy client in WildFly

[Sun8642]

Context

I’m using the belgif-rest-problem-java-ee library with WildFly 26.1.3.Final and Resteasy 4.7.7.Final.
However, it also includes client-side configuration (ProblemClientResponseFilter) annotated with @Provider.

When I try to use a RESTEasy client on WildFly (either from my API using the library or from another application running on the same server), Resteasy automatically registers this ProblemClientResponseFilter as a provider — even though it should only be used for JAX-RS clients.

Problem

When creating a RESTEasy client, RESTEasy tries to instantiate ProblemClientResponseFilter, which throws an exception (on constructor) because it’s not configured through ProblemSupport.enable(client).

This happens without explicitly enabling the Problem support on the client.
As a result, any JAX-RS client created in the application (or another deployed app on the same Wildfly) will fail to initialize correctly.

We want to allow the user to choose if he wants to use the problem support from the library or not. This @Provider forces us to enable the Problem support on the client. It's a real problem if we deploy several application on the same Wildfly, if we try to use other REASTEasy client configured to call other API (which don't use the belgif library), the ProblemClientResponseFilter will still be instantiated and exceptions will be thrown in both deployed war (the server using the library and the app trying to use any configured RESTEasy client)

Expected behavior

The ProblemClientResponseFilter should not be automatically registered as a global JAX-RS provider on the server.

It should only be registered when explicitly enabled via ProblemSupport.enable(client) in client code.

It should not affect other wars deployed on the same Wildfly.

Suggested fix

Remove the @Provider annotation from ProblemClientResponseFilter, and let it be registered only via ProblemSupport.enable(client).

Environment

WildFly: 26.1.3.Final

Resteasy: 4.7.7.Final

Library: belgif-rest-problem-java-ee (latest release as of now)

Java: 17

[jpraet]

You make a valid point, it is also being discussed in #252.

I am a bit surprised about "It should not affect other wars deployed on the same Wildfly."
I don't really see how it could affect other wars, as normally those have a separate classpath.
Or are you deploying rest-problem as a global shared library?

[Sun8642]

What I experienced — and what made the issue critical — is the following scenario:

• WAR A uses belgif-rest-problem on the server side only.
• WAR B uses the RESTEasy client provided by WildFly and does NOT depend on the belgif library.
• Both WARs are deployed on the same WildFly instance.
• When WAR B performs a REST call using RESTEasy, I get errors in both deployments:
  On WAR B:
  1. The REST call fails with an exception.
  2. This does not happen when WAR B is deployed on another WildFly instance where WAR A is not present.
  3. It also does not happen when using another HTTP client (no RESTEasy involved).
  On WAR A:
  1. I get a ClassNotFoundException for ProblemClientResponseFilter, because RESTEasy tries to instantiate it even though WAR B never references the belgif library.
  2. This does not happen if WAR B add the belgif library to dependencies and explicitly enables the client support via ProblemSupport.enable(client).

I was also surprised by this behaviour, but it really looks like RESTEasy uses a global provider registry inside WildFly.
Any class annotated with @Provider — even if only intended as a client-side filter — ends up being discovered and registered globally, and then reused across deployments.

This is why @Provider on a client-side filter becomes a problem and ends up affecting other WARs.

[Sun8642]

Hi, just checking in on this issue. Is there any update on the progress or timeline for a fix? Thanks!

[Raffine64]

This issue is also more or less related to this discussion: #252 (comment)

[jpraet]

Hi, no timelime but this issue is not being forgotten. #296 is a first step towards a solution.