Re: [keycloak-dev] User apps and HttpClient

@Vlastimil - a few questions: Do you use org.keycloak.adapters.HttpClientBuilder in your app?

Do you import any other class from org.keycloak.adapters in your app?

Do you package httpclient.jar within your .war by any chance?

Do you put jboss-deployment-structure.xml to your .war's /WEB-INF Does your jboss-deployment-structure.xml look like this: <jboss-deployment-structure> <deployment> <dependencies> <module name="org.apache.httpcomponents" slot="4.3"/> </dependencies> </deployment> </jboss-deployment-structure>

- m ----- Original Message ----- > Hi boys, > > we just hit same problem with our app running at EAP 6.4 and latest > Keycloak adapters 1.2.0.CR1 and Final1. > > I tried to play with <jboss-deployment-structure> of our app but no any > success. > > Is there any other solution than downgrade of Keycloak EAP adapter to > 1.2.0.Beta1 as we need solution ASAP? > Is 1.2.0.Beta1 EAP adapter is compatible with Keycloak server 1.2.0.Final? > > Other solution is rewrite our app not to use httpclient, but it is not > ideal solution too. > > Thanks in advance for some solution proposal. > > Vlastimil > > On 21.5.2015 22:56, Marko Strukelj wrote: >> We package examples with jboss-deployment-structure.xml that looks like >> this: >> >> >> <jboss-deployment-structure> >> <deployment> >> <dependencies> >> <module name="org.apache.httpcomponents"/> >> </dependencies> >> </deployment> >> </jboss-deployment-structure> >> >> >> If we drop a .war containing this into Wildfly 9 (distribution/server-dist >> - ATM distribution/demo-dist, and >> distribution/adapters/wildfly-adapter-zip look buggy as they still use >> slot=4.3), things are fine. >> >> However, if we dropped this into Wildfly 8 with keycloak adapter modules >> using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError >> as soon as some Keycloak logic is triggered by user app. >> >> The question: how come jboss modules isolation doesn’t kick in and allow >> keycloak adapter modules to use slot=4.3 while at the same time user app >> (our examples) uses slot=main? >> >> The answer is that org.keycloak.adapters.HttpClientBuilder which seems to >> be our helper class for org.apache.httpcomponents inevitably leaks the >> version of HttpClient its module refers to - can’t be any other way >> (unless we change the code to use client app’s classloader - opening a can >> of worms). Any user app using HttpClientBuilder.build() method receives an >> instance of HttpClient loaded through org.keycloak.keycloak-adapter-core >> module, and transitively through org.apache.httpcomponents referred to >> therein. >> >> Any attempt of an application (.war) to package its own httpcomponents >> jars, or to refer to a different jboss module than the exact one referred >> to by org.keycloak.keycloak-adapter-core will result in ‘catastrophic >> failure’. Example: >> >> >> HttpClient client = new >> HttpClientBuilder().disableTrustManager().build(); >> >> >> HttpClient on the left is loaded by app’s classloader. The one returned by >> build() on the right is loaded by org.keycloak.keycloak-adapter-core >> module’s version of httpcomponents. If it’s not the same classloader >> (jboss module) on both sides loading HttpClient you get a LinkageError. >> >> >> In light of this I wonder if it wasn’t the best solution to reexport >> org.apache.httpcomponents to .wars by default, thereby removing the >> necessity to package jboss-deployment-structure.xml at all, and ensuring >> that user application always uses the proper module. >> >> Currently jboss-deployment-structure.xml is required for wildfly / as7, and >> is a nuisance, especially as it has to be different (refer to slot=4.3) >> for Wildfly 8. >> >> If using HttpClientBuilder is supposed to be completely optional, we could >> maybe add configuration to keycloak subsystem to control exposing it to >> all or specific secure deployments. >> >> We could simply add another common attribute that can be used in <realm> >> and <secure-deployment>. We could expose it by default and have something >> like: >> >> <expose-httpcomponents>false</expose-httpcomponents> >> >> to inhibit exposing it if a situation calls for it. >> >> >> WDYT? >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev