ClassNotFoundException for org.jboss.resteasy.client.jaxrs.internal.proxy.ProxyBuilderImpl

[jringbox]

I'm having a difficult time with an issue on context related to resteasy-client-api 6.2.4. For some reason I'm getting this exception.

2025-03-12 13:40:47,863 {HH:mm:ss.SSS} [ForkJoinPool.commonPool-worker-7] ERROR c.i.c.u.p.e.l.InterceptorWorker - An error occurred while processing an event
java.lang.RuntimeException: Invocation target error for method [search]
        at XXXX (BasePresenter.java:306)
        at XXXX (InterceptorWorker.java:502)
        at XXXX (InterceptorWorker.java:151)
        at XXXX.thread.UIFuture.lambda$run$2(UIFuture.java:153)
        at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
        at java.base/java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
        at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)
Caused by: java.lang.reflect.InvocationTargetException: null
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at XXXX
        ... 10 common frames omitted
Caused by: java.lang.RuntimeException: java.lang.ClassNotFoundException: org.jboss.resteasy.client.jaxrs.internal.proxy.ProxyBuilderImpl
        at org.jboss.resteasy.client.jaxrs.ProxyBuilder.builder(ProxyBuilder.java:36)
        at org.jboss.resteasy.client.jaxrs.internal.ClientWebTarget.createProxyBuilder(ClientWebTarget.java:99)
        at org.jboss.resteasy.client.jaxrs.internal.ClientWebTarget.proxy(ClientWebTarget.java:87)
        at org.keycloak.admin.client.spi.ResteasyClientClassicProvider.targetProxy(ResteasyClientClassicProvider.java:48)
        at org.keycloak.admin.client.Keycloak.realms(Keycloak.java:142)
        at org.keycloak.admin.client.Keycloak.realm(Keycloak.java:146)
        at XXXX (KeycloakGroupAcquirer.java:207)
        at XXXX
        at XXXX
        ... 15 common frames omitted
Caused by: java.lang.ClassNotFoundException: org.jboss.resteasy.client.jaxrs.internal.proxy.ProxyBuilderImpl
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)
        at org.jboss.resteasy.client.jaxrs.ProxyBuilder.builder(ProxyBuilder.java:32)
        ... 23 common frames omitted

In org.jboss.resteasy.client.jaxrs.ProxyBuilder, there's this line of code.

Class clazz = loader.loadClass("org.jboss.resteasy.client.jaxrs.internal.proxy.ProxyBuilderImpl");

This line is failing and it's unable to find the class. The class is in resteasy-client.

Before this line of code occurs, there's loader = Thread.currentThread().getContextClassLoader(); which get's the loader to find ProxyBuilderImpl. Now if I do Thread.currentThread().setContextClassLoader(org.jboss.resteasy.client.jaxrs.ProxyBuilder.class.getClassLoader()); before that line is called, everything works fine. What I'm confused by is why the loader can't resolve the class. My build does contain resteasy-client and resteasy-client-api in my build and deployment.

As a note, I'm using Java 17 Jakarta in Jetty 12 standalone server and I've been upgrading from resteasy 3.0.24 and from Spring Boot 2.3.4 to 3.4.3.

I'm sure this is a dependency issue of some sort but I don't know what is causing this. If anyone have any ideas, I would appreciate it.

[jamezp]

That is definitely strange. I don't know Jetty all that well as I've just not used it much. If you have a reproducer, I'm happy to have a look. Where I would start looking is to see what Thread.currentThread().getContextClassLoader() returns. My guess is it's a Jetty class loader. Which if that's the case, that means it must not have visibility to the deployment.

[jamezp]

Interesting. RESTEasy currently does not support JPMS because of not all of it's components do. This is likely something that needs to be addressed, see https://issues.redhat.com/browse/RESTEASY-3011.

That said we could try doing something like:

Class clazz;
try {
    clazz = loader.loadClass("org.jboss.resteasy.client.jaxrs.internal.proxy.ProxyBuilderImpl");
} catch (ClassNotFoundException ignore) {
    clazz = ProxyBuilder.class.getClassLoader().loadClass("org.jboss.resteasy.client.jaxrs.internal.proxy.ProxyBuilderImpl");
}

That would work around this issue and might actually be the right thing to do until JPMS can be done in RESTEasy.

[jringbox]

That should fix it. Hope that can be rolled out soon. I'll need that fix as soon as it's available. As fyi, I just executed that line of code in that context (ie breakpoint in IDE) and that logic executes successfully with no error/exception in the catch block.

[jamezp]

Sorry for the delay on this. Can you give me a bit of context on what your setup looks like? I'm trying to figure out how I could reproduce this.

[jringbox]

Currently, I have an authorization library that provides a keycloak admin client instance. The instance is created as follows in a @PostConstruct annotated init method in a base class.

Client client = ResteasyClientBuilder.newBuilder()
  .readTimeout(socketTimeout, TimeUnit.MILLISECONDS)
  .connectTimeout(establishConnectionTimeout, TimeUnit.MILLISECONDS)
  .trustStore(keyStore)
  .register(CustomResteasyJackson2Provider.class)
  .build();

keycloak = KeycloakBuilder.builder()
  .clientId(clientId)
  .clientSecret(clientSecret)
  .grantType(OAuth2Constants.CLIENT_CREDENTIALS)
  .realm(realm)
  .serverUrl(serverUrl)
  .resteasyClient(client)
  .build();

Later in the code, calls such as keycloak.realm(realm).groups().group(id).toRepresentation(); and keycloak.realm(realm).users().get(id).toRepresentation(); are made from dedicated class implementation for user and group that extends this base class. The user and group acquirers beans are wired up in Spring via XML

The failure of these calls is when the realm method is invoked which can be seen in the stack trace I posted. What is troubling is that the class loader is jdk.internal.loader.ClassLoaders rather than org.eclipse.jetty.ee10.webapp.WebAppClassLoader since I'm using Jetty 12 EE10 configuration. I'm not sure if or how JPMS fits into what is going on.

I had similar issues with quartz where class loader was failing. For quartz, I defined a custom class load helper and set that property on my custom SchedulerFactoryBean class for Spring. When I did this, the default class loader for quartz wasn't used and my custom class loader was used for class resolutions which fixed my problem. I was hoping that ResteasyClientBuilder had a setter method called "classLoader" where a custom class loader could be provided. This would be a clean approach to address the class loading issues and could be used in other context areas of RESTEasy.

[jamezp]

First of all, sorry I completely let this slip. I filed https://issues.redhat.com/browse/RESTEASY-3598 which I will get a fix for ASAP.

[nandadomenicali]

Hey, jringbox

✅ Possible Solutions
Solution 1: Explicitly Add Resteasy Modules
Make sure your dependencies explicitly declare all required modules:

<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-client</artifactId>
    <version>6.2.4.Final</version>
</dependency>
<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-client-api</artifactId>
    <version>6.2.4.Final</version>
</dependency>
<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-core</artifactId>
    <version>6.2.4.Final</version>
</dependency>
<dependency>
    <groupId>jakarta.ws.rs</groupId>
    <artifactId>jakarta.ws.rs-api</artifactId>
    <version>3.1.0</version>
    <scope>provided</scope>
</dependency>

[jringbox]

ClassNotFoundException still occurs with this fix.

[jringbox]

I ran into another problem where my code is packaged in a different context and cxf-rt-rs-client library was instead of the one for RESTEasy. This caused this exception when build() was done on ResteasyClientBuilder.newBuilder() as follows.

java.lang.ClassCastException: Cannot cast org.apache.cxf.jaxrs.client.spec.ClientImpl$WebTargetImpl to org.jboss.resteasy.client.jaxrs.ResteasyWebTarget

To resolve this, I had to exclude cxf-rt-rs-client. So, it was choosing Apache CXF instead of RESTEasy when it threw this exception from the build() operation. This was all about class loader not finding the right context. My question on this is what about other areas of code that a developer may want to use cxf-rt-rs-client? I excluded the choices and now RESTEasy is the only choice because of context issues. Somehow RESTEasy needs to understand context on what to choose, hence class loader...unless I am understanding this all wrong and I'm missing something here.

[jamezp]

The newBuilder() is a static method inherited by the jakarta.ws.rs.client.ClientBuilder. That's not something we can override. What the method does is a lookup for a the builder implementation with a service loader. There is nothing RESTEasy can do to control it's class path. It could be all kinds of different environments it is run in.

[jringbox]

That's a real Jakarta framework problem if you ask me.

[jamezp]

Well, it's just a class path issue in general IMO. It's just a ServiceLoader so the class path order matters.

[heruan]

I'm experiencing the same issue running an app built with Spring Boot 3.4.4 and using the Keycloak 26.0.5 Java API:

java.lang.ClassNotFoundException: org.jboss.resteasy.client.jaxrs.internal.proxy.ProxyBuilderImpl
    at org.jboss.resteasy.client.jaxrs.ProxyBuilder.builder(ProxyBuilder.java:36) ~[resteasy-client-api-6.2.9.Final.jar:6.2.9.Final]
    at org.jboss.resteasy.client.jaxrs.internal.ClientWebTarget.createProxyBuilder(ClientWebTarget.java:99) ~[resteasy-client-6.2.9.Final.jar:6.2.9.Final]
    at org.jboss.resteasy.client.jaxrs.internal.ClientWebTarget.proxy(ClientWebTarget.java:87) ~[resteasy-client-6.2.9.Final.jar:6.2.9.Final]
    at org.keycloak.admin.client.spi.ResteasyClientClassicProvider.targetProxy(ResteasyClientClassicProvider.java:48) ~[keycloak-admin-client-26.0.5.jar:26.0.
    at org.keycloak.admin.client.Keycloak.realms(Keycloak.java:142) ~[keycloak-admin-client-26.0.5.jar:26.0.5]
    at org.keycloak.admin.client.Keycloak.realm(Keycloak.java:146) ~[keycloak-admin-client-26.0.5.jar:26.0.5]

@jringbox did you manage to find a workaround for this?

[heruan]

Thanks, I'll try. Eventually this needs to work in a natively compiled image with Spring Boot, so I expect any workaround not to last long when I get there. Hope this gets fixed soon!

[jamezp]

The issue with JPMS modules is all dependencies also need to include JPMS modules. We need to do a comprehensive analysis of the dependencies and see what we can do here. It would be really nice to create modules for these projects, but things like the version of Apache HTTP Client we use aren't JPMS modules so it complicates things :)

[jringbox]

As fyi, I tried --add-opens org.jboss.resteasy.client.jaxrs/org.jboss.resteasy.client.jaxrs.internal.proxy=ALL-UNNAMED. That didn't work. I had to go back to my custom build of the library.

[heruan]

Hey guys, having hard time with this and also to follow the discussion here with all the sub-threads 😵‍💫 Is there a proper GitHub issue to follow to fix this? I would create one but I still don't understand all the intricacies of this as I don't know much about JPMS 😞

[jamezp]

@heruan The JPMS issue is https://issues.redhat.com/browse/RESTEASY-3011. It might unfortunately be a while before it's resolved. It's something I will try to have a look at soon though.