Java-ee: server-side annotated class should be separated from client-side

[Raffine64]

Problem

I would like to create a RESTEasy client that uses the belgif-rest-problem-java-ee library, and then reuse that library in other existing web service projects where belgif-rest-problem-java-ee is not currently used.

The issue is that the library does not contain only client-side classes — it also includes server-side annotated classes, which are automatically activated and cause conflicts.

Suggested fix

Split the library into two separate JARs, each containing the appropriate classes:

belgif-rest-problem-java-ee-client: contains only client-side classes
belgif-rest-problem-java-ee-server: contains only server-side classes

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]

I think we can do this, also keeping the current belgif-rest-problem-java-ee around, which can bring in both belgif-rest-problem-java-ee-client and belgif-rest-problem-java-ee-server.

This solves the issue where you only want to enable the problem library only on the client or server side.

But when we take it a bit further: what if you have an application that exposes / consumes multiple API's, where some of them use problems, and others don't? Do we also need a mechanism to selectively enable the problem library on a per-API basis?

[Raffine64]

We have the case where we have applications that will make a mix of usages, some of them using a client that would rely on belgif-rest-problem-java-ee-client, and other that don't.

One of the problem we face, is that the libs takes decisions for you globally, like using CDI.

A client should remain in the sphere of influence of resteasy client, using client-side filters you can register when you create the client.

Resteasy don't force you to use CDI, and we also have projects that conflicts with CDI, making the client with belgif-rest-problem-java-ee impossible to use.

So all the logic for a client should remain limited to that client instance, and like this we don't bleed the logic elsewhere, on other clients.

[jpraet]

The intent of this rest-problem library so far has been to add automatic transparent support for these problems in Spring Boot / Jakarta EE / Quarkus applications, without having to register / configure anything. Just add the dependency and you're all set.

But as you mention, I can see that being a problem in environments where not all APIs are using problems. Maybe it is possible to further split off some *-core modules, which don't contain the auto-configuration magic, and can be used in applications that require more selective control about which endpoints / clients need problem support enabled.

Alternatively, maybe a system property to disable auto-configuration could also work.

[Raffine64]

Based on documentation: https://belgif.github.io/rest-problem-java/latest/#getting-started-jakarta-ee

You have different kind of clients:

• JAX-RS client
• RESTEasy Proxy Framework

And for instance for a resteasy client you have to do client = ProblemSupport.enable(client) to activate.
Problem is that behind the scene it forces you to use CDI, and registers stuff even if you don't enable problem support.
This activation should be limited to the client in which you ask for activation.

Those types of clients don't force you to use CDI, leaving them kind of portable, provided you give the implementation.

CDI also is not easy to test, so when we do integration tests, we have to provide a container, where normally, only the implementation would be required.

Note: MicroProfile REST Client requires CDI.

[jpraet]

Getting rid of CDI would be quite difficult. It is currently used for automatic discovery of the problem types present on the classpath.
Without CDI, we would need to introduce a dependency to a classpath scanning library. CDI lies at the core of Jakarta EE, so it seems reasonable to depend on it.

[jpraet]

Splitting belgif-rest-problem-java-ee would mean replacing it by 6 modules:

• belgif-rest-problem-java-ee-server
• belgif-rest-problem-java-ee-client
• belgif-rest-problem-java-ee-common (shared between server and client)
• belgif-rest-problem-jakarta-ee-server
• belgif-rest-problem-jakarta-ee-client
• belgif-rest-problem-jakarta-ee-common

That is because the current approach for making the "jakarta" classifier variant of belgif-rest-problem-java-ee doesn't work when the library is split up. There is no way to configure that the "jakarta" classifier of belgif-rest-problem-java-ee-server should depend on the "jakarta" classifier of belgif-rest-problem-java-ee-common.

The issue is that the library does not contain only client-side classes — it also includes server-side annotated classes, which are automatically activated and cause conflicts.

@Raffine64 Could you elaborate: which server-side classes are causing what kind of conflicts?

[Raffine64]

For instance, let say i have the following situation:

WS A (legacy, no beligf) => uses client WS B (with belgif) => WS B (with belgif)

Client WS B includes belgif libs, and also exception mappers which are normally server-side annotations.
As WS A is also a WS, it registers as well those annotations, which I don't want, I have to provide my own.

[jpraet]

Would a solution with a io.github.belgif.rest.problem.server-side-enabled property (which you can set to false via system property, environment variable, or web.xml context-param) be acceptable to you?

[Raffine64]

I would prefer a clean separation of concern solution.

Solutions where you still have annotations that triggers could add extra unnecessary processing as well.