For now let's update the examples to not use internal classes, including
JsonSerialization which Marek pointed out. I think the only class examples/demos should
use are KeycloakSecurityContext and very few examples even needs that.
Marking modules as private needs to be done as part of a bigger task, so don't do
anything yet. We need to clearly define what classes/interfaces/modules are internal and
which are public. It'll be easier for adapters than for the server, so we should
probably start there, but we have other higher priority tasks atm.
----- Original Message -----
From: "Marko Strukelj" <mstrukel(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
Sent: Friday, 22 May, 2015 9:38:49 AM
Subject: Re: [keycloak-dev] User apps and HttpClient
That's a great solution :)
I suppose most / all? of adapter modules should also be marked as internal
modules, so that there is a warning in the log if a user pulls them in as
dependencies.
----- Original Message -----
>
>
> ----- Original Message -----
> > From: "Marko Strukelj" <mstrukel(a)redhat.com>
> > To: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
> > Sent: Thursday, 21 May, 2015 10:56:40 PM
> > Subject: [keycloak-dev] User apps and HttpClient
> >
> > 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.
>
> HttpClientBuilder is an internal helper class and shouldn't be used
> directly
> by applications. We just need to rewrite the examples to not use it and
> Bob's your uncle the problem is no longer ;)
>
> >
> >
> > 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
>