I have deployed Keycloak inside of an embedded Tomcat server, all running inside a Docker container. Keycloak is able to successfully authenticate with my SSO Server, however the web application is not displaying any images or style sheets. If I attempt to access an image by providing the fully qualified URL I get the following stacktrace. This application runs perfectly when not configured to use Keycloak.
*HTTP Status 500 - org.keycloak.adapters.servlet.OIDCFilterSessionStore$SerializableKeycloakAccount cannot be cast to org.keycloak.adapters.servlet.OIDCFilterSessionStore$SerializableKeycloakAccount
type Exception report
message org.keycloak.adapters.servlet.OIDCFilterSessionStore$SerializableKeycloakAccount cannot be cast to org.keycloak.adapters.servlet.OIDCFilterSessionStore$SerializableKeycloakAccount
description The server encountered an internal error that prevented it from fulfilling this request.
exception
java.lang.ClassCastException: org.keycloak.adapters.servlet.OIDCFilterSessionStore$SerializableKeycloakAccount cannot be cast to org.keycloak.adapters.servlet.OIDCFilterSessionStore$SerializableKeycloakAccount
org.keycloak.adapters.servlet.OIDCFilterSessionStore.checkCurrentToken(OIDCFilterSessionStore.java:72)
org.keycloak.adapters.servlet.KeycloakOIDCFilter.doFilter(KeycloakOIDCFilter.java:191)
note The full stack trace of the root cause is available in the Apache Tomcat/7.0.37 logs.
Apache Tomcat/7.0.37*
Sounds like you have multiple instances of some of the Keycloak jars in your classpath. The class org.keycloak.adapters.servlet.OIDCFilterSessionStore lives in keycloak-servlet-filter-adapter-<version>.jar. Most IDE’s will give you an exploded view of your dependency hierarchy, check that for conflicting versions. It’s also possible that something in your deployment is dropping duplicate jars.
Thanks for your reply. In my case we are leveraging a maven pom.xml to define the deployment, and we’re deploying to a container environment. One by-product of this is it deploys everything from scratch every time as it by nature starts with an empty maven (.m2) repository directory and downloads everything during the build step. If multiple copies of the same keycloak jar files were being deployed then they would simply overwrite each other.
Thanks for the clarification on your setup - you are correct that maven wouldn’t drop duplicates for the same jars.
So, the underlying issue is that your JVM knows about two (or more) versions of the class OIDCFilterSessionStore$SerializableKeycloakAccount. That’s the object stored in a session so I’m guessing the code putting the object into session is using a different class version than the one your filter is using.
That could be because your maven build is referencing multiple versions of the keycloak instance (you’re using version X but a dependency is expecting version Y).
Alternatively, it could be because the instance’s class was loaded by one classloader, and then is being cast to a class loaded by a different classloader. This could happen if one’s loading from something like Spring and the other isn’t. That scenario is a bit harder to troubleshoot. You might be able to verify that by attaching JConsole to your running instance and checking the loaded classes or by attaching a remote debugger (JDPA) and stepping through the problem code in real time.
I hope those gave you some ideas to try, classloader problems can be very tricky.
1 Like