Honestly, I don't remember if the keycloak jars can be contained in your WAR as the different versions of Jetty and Tomcat are a blur to me at this time. I do think I had to do it that way for Tomcat. Keycloak runs as a valve and has to have visibility to other Tomcat system classes. On 11/12/2015 10:41 AM, Tim Dudgeon wrote: > When deploying the Tomcat adapter (presumably the same applies to other > containers) I find that the 3rd party libs needed by the Keycloak > adapter can clash with different versions of the same libs deployed with > a web app. For instance I just needed to spend quite a bit of time > finding out why a webapp would not deploy, and it resulted from > bcprov-jdk15on-1.50.jar provided by Keycloak, and hence in the Tomcat > lib dir and bcprov-jdk15on-1.53.jar in my application and hence in the > webapp's WEB-INF/lib dir. > Some of these 3rdparty libs are quite common and might be be expected in > many web apps. > > The docs state that the Keycloak libs must be deployed to the lib dir. > Presumably there's no way round that and hence no way around potential > conflicts? > IIRC, there's not much classloader isolation you can do in Tomcat. jars in WEB-INF/lib are supposed to take precedence over those in system classpath. I don't remember exactly, but I believe that keycloak jars and dependencies needed to be in tomcat lib dir because Keycloak runs as a valve and has to have visibility to other Tomcat system classes. I'm just not sure how else we can solve this issue. If you have any suggestings that would be great.

Like I said, there's not much you can do about that because Tomcat's classloader isolation is limited. We don't have that problem with JBoss/Wildfly. I'm not sure what you want us to do as we need these third-party libs for the adapter to function. What you could do is attempt to replace our dependency with whatever version you are using. I do know that Jackson 1.x can coexist with Jackson 2.x. Not sure about bouncycastle and Apache HTTP Client. On 11/12/2015 3:25 PM, Tim Dudgeon wrote: > Even if it can be moved inside the WAR that doesn't really solve the > problem. > You still have the potential clash of xyzlib-0_1_2.jar (specified > Keycloak) with xyzlib-0_1_3.jar (specified by webapp). > > On 12/11/2015 20:06, Bill Burke wrote: >> Honestly, I don't remember if the keycloak jars can be contained in your >> WAR as the different versions of Jetty and Tomcat are a blur to me at >> this time. I do think I had to do it that way for Tomcat. Keycloak >> runs as a valve and has to have visibility to other Tomcat system classes. >> >> >> >> On 11/12/2015 10:41 AM, Tim Dudgeon wrote: >>> When deploying the Tomcat adapter (presumably the same applies to other >>> containers) I find that the 3rd party libs needed by the Keycloak >>> adapter can clash with different versions of the same libs deployed with >>> a web app. For instance I just needed to spend quite a bit of time >>> finding out why a webapp would not deploy, and it resulted from >>> bcprov-jdk15on-1.50.jar provided by Keycloak, and hence in the Tomcat >>> lib dir and bcprov-jdk15on-1.53.jar in my application and hence in the >>> webapp's WEB-INF/lib dir. >>> Some of these 3rdparty libs are quite common and might be be expected in >>> many web apps. >>> >>> The docs state that the Keycloak libs must be deployed to the lib dir. >>> Presumably there's no way round that and hence no way around potential >>> conflicts? >>> >> IIRC, there's not much classloader isolation you can do in Tomcat. jars >> in WEB-INF/lib are supposed to take precedence over those in system >> classpath. >> >> I don't remember exactly, but I believe that keycloak jars and >> dependencies needed to be in tomcat lib dir because Keycloak runs as a >> valve and has to have visibility to other Tomcat system classes. I'm >> just not sure how else we can solve this issue. If you have any >> suggestings that would be great. >> >> > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user >