[keycloak-dev] User apps and HttpClient

[Stan Silvert]

Can you use slot=4.3 for your app?

On 5/22/2015 8:09 AM, Vlastimil Elias wrote:
> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev