Repository navigation
|
I've migrated my app from Keycloak 12 to 23 and from RESTEasy 3.0.24 to 6.2.11. Everything is Java 17 EE10 Jakarta on all dependencies and I'm using Spring 6.2 with Spring Boot 3.4. When my application tries to access information from keycloak through my acquirer class, I get ClassNotFoundException. I checked my Jetty 12 directory with the exploded app in the work directory. I see the resteasy-client jar for 6.2.11 is included under lib directory. So there's no issue. Does anyone know why this is happening or how I might resolve this issue? |
Replies: 2 comments 8 replies
You'll need to see if anything setting a context class loader that you don't expect, or double check your expections for jetty app packaging. If you can attach a debugger and/or add debugging code in KeycloakUserAccountAcquirer - you should be able to check what the Thread.currentThread().getContextClassLoader() is set to - the class loader in use must not have access to the app classes you expect. |
|
Just talked to someone about this and if I can't figure out what is causing the keycloak admin client to fail then the best answer might be to not use it at all. Instead, I'll probably have to rewrite the acquirer to call the Keycloak admin API rest service directly which is probably what the client API does. Hate to take this refactor approach though. Let me see what I figure out. |
|
If the AppClassLoader is effectively the parent / server classloader managed by Jetty, then you can try instead of packaging the transitive dependencies in the app lib, put them in a server classpath location https://jetty.org/docs/jetty/12/operations-guide/start/index.html#start-class-path |
|
I tried "resources" and "lib/ext" directory and neither worked. Also, I think my reasoning on "jdk.internal.loader.ClassLoaders" for Java 17 and "org.eclipse.jetty.webapp.WebAppClassLoader" for Java 8 is flawed. When I upgraded from Jetty 9 to Jetty 12, the class loading mechanism changed. Jetty 12 uses the Jakarta namespace which makes it rely more on the Java Platform Module System (JPMS) introduced in Java 9 from what I understand. For this reason, I believe this means that seeing "jdk.internal.loader.ClassLoaders" being used could be correct rather than seeing "org.eclipse.jetty.webapp.WebAppClassLoader". As far as what is causing this issue, it's as you say, I need to dive into the Jetty 12 class loading mechanism to figure out what is going wrong. However, I think that may be a very complicated investigation to pursue. Right now, I have a POJO using keycloak-admin-client and making a call to the provider I have with no issues. So I guess the next step is putting this into a Jetty context, then Spring context, and so on until I'm out of framework contexts for class loaders. Not a pretty approach but I may figure out who is the culprit this way. |
|
The issue appears to be related to context with RESTeasy. I posted an inquiry to this issues. https://github.com/orgs/resteasy/discussions/4538 So far, what I ended up doing was creating a customized version of |
|
I have roughly the same situation (migrating from Keycloak 17 to 26 and Spring 2 to 3) and hit the same error. After some debugging, my root cause was a combination of:
Old version of resteasy doesn't seem to make this It is painful trying to change the ClassLoader cl = Thread.currentThread().getContextClassLoader();
// should be Spring LaunchedURLClassLoader since all classes are only loadable with it
Thread.currentThread().setContextClassLoader(AnyClassInMyClassPath.class.getClassLoader())
Keycloak = createKeycloak();
Thread.currentThread().setContextClassLoader(cl); |
The issue appears to be related to context with RESTeasy. I posted an inquiry to this issues.
https://github.com/orgs/resteasy/discussions/4538
So far, what I ended up doing was creating a customized version of
resteasy-client-apithat usesProxyBuilder.class.getClassLoader().loadClass("org.jboss.resteasy.client.jaxrs.internal.proxy.ProxyBuilderImpl")in the catch block. This is what the maintainer of the project suggested. This change in the code fixed my issues though I did suggest that a setter for classloader would be a better solution.