3:56 p.m.
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?
6:58 p.m.
On 5/21/2015 4:56 PM, 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?
What do I think? I think that classloading questions always make my
head hurt!
The best solution would be to find a way to detect the problem and fix
it at deploy time. Using a DependencyProcessor, it should be possible
to detect that the deployment contains the same module from two
different slots. Then pick the best slot and spit out a warning message
that you are removing the undesirable module.
It should be possible, but I don't know if it actually _IS_ possible. A
version mismatch between modules is like a cancer. I think you should
speak to an oncologist or David Lloyd. Since Red Hat doesn't employ any
oncologists, go with David. :-)
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:50 a.m.
I like Stian's solution much better ... it's much simpler :)
@Stian: Is there some docs where I can get a better understanding of what's an API
that is exposed to client, and what is implementation details never to be used by client
apps ...
Ideally that would be easy to establish based on package names - e.g. anything not in
org.keycloak.something.impl might be an API, or nothing but what's in
org.keycloak.something.api might be an API ...
Or maybe we have one single module that's client API?
----- Original Message -----
On 5/21/2015 4:56 PM, 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?
What do I think? I think that classloading questions always make my
head
hurt!
The best solution would be to find a way to detect the problem and
fix it at
deploy time. Using a DependencyProcessor, it should be possible to detect
that the deployment contains the same module from two different slots. Then
pick the best slot and spit out a warning message that you are removing the
undesirable module.
It should be possible, but I don't know if it actually IS
possible. A version
mismatch between modules is like a cancer. I think you should speak to an
oncologist or David Lloyd. Since Red Hat doesn't employ any oncologists, go
with David. :-)
> _______________________________________________
> keycloak-dev mailing list keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:59 a.m.
For now let's just make sure examples don't use HttpClientBuilder. That should be
relatively quick to fix and solves you're problem. We can worry about the rest later
when we start defining public/private stuff.
----- Original Message -----
From: "Marko Strukelj" <mstrukel(a)redhat.com>
To: "Stan Silvert" <ssilvert(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Friday, 22 May, 2015 9:50:27 AM
Subject: Re: [keycloak-dev] User apps and HttpClient
I like Stian's solution much better ... it's much simpler :)
@Stian: Is there some docs where I can get a better understanding of what's
an API that is exposed to client, and what is implementation details never
to be used by client apps ...
Ideally that would be easy to establish based on package names - e.g.
anything not in org.keycloak.something.impl might be an API, or nothing but
what's in org.keycloak.something.api might be an API ...
Or maybe we have one single module that's client API?
On 5/21/2015 4:56 PM, 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?
What do I think? I think that classloading questions always make my head
hurt!
The best solution would be to find a way to detect the problem and fix it at
deploy time. Using a DependencyProcessor, it should be possible to detect
that the deployment contains the same module from two different slots. Then
pick the best slot and spit out a warning message that you are removing the
undesirable module.
It should be possible, but I don't know if it actually IS possible. A version
mismatch between modules is like a cancer. I think you should speak to an
oncologist or David Lloyd. Since Red Hat doesn't employ any oncologists, go
with David. :-)
_______________________________________________
keycloak-dev mailing list keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3 a.m.
----- Original Message -----
From: "Stian Thorgersen" <stian(a)redhat.com>
To: "Marko Strukelj" <mstrukel(a)redhat.com>
Cc: "Stan Silvert" <ssilvert(a)redhat.com>, keycloak-dev(a)lists.jboss.org
Sent: Friday, 22 May, 2015 9:59:23 AM
Subject: Re: [keycloak-dev] User apps and HttpClient
For now let's just make sure examples don't use HttpClientBuilder. That
should be relatively quick to fix and solves you're problem. We can worry
about the rest later when we start defining public/private stuff.
You're not the problem, I obviously meant your problem ;)
----- Original Message -----
> From: "Marko Strukelj" <mstrukel(a)redhat.com>
> To: "Stan Silvert" <ssilvert(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Friday, 22 May, 2015 9:50:27 AM
> Subject: Re: [keycloak-dev] User apps and HttpClient
>
> I like Stian's solution much better ... it's much simpler :)
>
> @Stian: Is there some docs where I can get a better understanding of what's
> an API that is exposed to client, and what is implementation details never
> to be used by client apps ...
>
> Ideally that would be easy to establish based on package names - e.g.
> anything not in org.keycloak.something.impl might be an API, or nothing but
> what's in org.keycloak.something.api might be an API ...
> Or maybe we have one single module that's client API?
>
>
>
>
>
>
> On 5/21/2015 4:56 PM, 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?
> What do I think? I think that classloading questions always make my head
> hurt!
>
> The best solution would be to find a way to detect the problem and fix it
> at
> deploy time. Using a DependencyProcessor, it should be possible to detect
> that the deployment contains the same module from two different slots. Then
> pick the best slot and spit out a warning message that you are removing the
> undesirable module.
>
> It should be possible, but I don't know if it actually IS possible. A
> version
> mismatch between modules is like a cancer. I think you should speak to an
> oncologist or David Lloyd. Since Red Hat doesn't employ any oncologists, go
> with David. :-)
>
>
>
> _______________________________________________
> keycloak-dev mailing list keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
6 a.m.
On 5/22/2015 3:50 AM, Marko Strukelj wrote:
I like Stian's solution much better ... it's much simpler :)
Yea, to extend the medical metaphor, it's like the guy who goes in to
see the doctor. He raises his arm in a funny way and says, "Hey doc, it
hurts when I do this." Doctor says, "Don't do that."
@Stian: Is there some docs where I can get a better understanding of
what's an API that is exposed to client, and what is implementation
details never to be used by client apps ...
Ideally that would be easy to establish based on package names - e.g.
anything not in org.keycloak.something.impl might be an API, or
nothing but what's in org.keycloak.something.api might be an API ...
Or maybe we have one single module that's client API?
------------------------------------------------------------------------
On 5/21/2015 4:56 PM, 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?
What do I think? I think that classloading questions always make
my head hurt!
The best solution would be to find a way to detect the problem and
fix it at deploy time. Using a DependencyProcessor, it should be
possible to detect that the deployment contains the same module
from two different slots. Then pick the best slot and spit out a
warning message that you are removing the undesirable module.
It should be possible, but I don't know if it actually IS
possible. A version mismatch between modules is like a cancer. I
think you should speak to an oncologist or David Lloyd. Since Red
Hat doesn't employ any oncologists, go with David. :-)
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2 a.m.
----- 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
2:35 a.m.
On 22.5.2015 09:00, Stian Thorgersen wrote:
----- 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 ;)
Not directly related, but I wonder if we should do the
same for
JsonSerialization class? I remember some time ago someone complained on
keycloak-user ML that something doesn't work for him as expected and
you or Bill answered that it's just internal class. However since our
examples are using it, we can't expect people to not use it in their own
apps ;-)
Marek
>
> 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
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:38 a.m.
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
2:49 a.m.
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
>
7:09 a.m.
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
7:36 a.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:36 a.m.
@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
7:48 a.m.
Hi,
On 22.5.2015 14:36, Marko Strukelj wrote:
@Vlastimil - a few questions:
Do you use org.keycloak.adapters.HttpClientBuilder in your app?
yes, colleague (in
CC) who create the code used some example how to call
Keycloak REST API from java code, so he uses this
Do you import any other class from org.keycloak.adapters in your app?
no
Do you package httpclient.jar within your .war by any chance?
no
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>
Yes. I tried this both with and without slot="4.3" attribute but error
is here in both cases.
A bit strange thing is that LinkageError has been thrown in finally
block on call of
client.getConnectionManager().shutdown();
When I commented this out then LinkageError arrised at line with
HttpResponse response = client.execute(get);
call, which is still not first occurence of httpclient in the method,
but I understand that it is classloading problem which is always strange ;-)
Thanks in advance
Vl.
- 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
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
8:15 a.m.
----- Original Message -----
Hi,
On 22.5.2015 14:36, Marko Strukelj wrote:
> @Vlastimil - a few questions:
>
> Do you use org.keycloak.adapters.HttpClientBuilder in your app?
yes, colleague (in CC) who create the code used some example how to call
Keycloak REST API from java code, so he uses this
Ok, in this case you have to make sure to include jboss-deployment-structure.xml that adds
dependency on org.apache.httpcomponents. To make sure you use the right slot, open the
modules/org/keycloak/keycloak-adapter-core/main/module.xml (could be in
modules/system/layers/base). In that file find dependency on org.apache.httpcomponents and
check if it has a slot="4.3".
In your jboss-deployment-structure.xml you have to use the same dependency. That's
all. Things should then work.
Or another option that Stian suggested ... don't use HttpClientBuilder at all. Forget
about it. Use HttpClient directly. I think in that case it's up to you how you provide
HttpClient to your .war. Haven't yet tried though. That one is on TODOs ...
> Do you import any other class from org.keycloak.adapters in your
app?
no
> Do you package httpclient.jar within your .war by any chance?
no
> 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>
Yes. I tried this both with and without slot="4.3" attribute but error
is here in both cases.
One of these cases should be a solution to your problem.
A bit strange thing is that LinkageError has been thrown in finally
block on call of
client.getConnectionManager().shutdown();
When I commented this out then LinkageError arrised at line with
HttpResponse response = client.execute(get);
call, which is still not first occurence of httpclient in the method,
but I understand that it is classloading problem which is always strange ;-)
Sounds like there is more going on here than what I initially described. There might be
more ways of erroneous interaction between multiple versions of HttpClient than we
currently see.
If you could make a reproducer and add it to JIRA that would be great ... as I'm a bit
in the dark here now.
It could be related to this issue: https://issues.jboss.org/browse/KEYCLOAK-1338
- m
1:16 a.m.
Hi Marko,
thanks, I'll try to prepare reproducer project and attach it to the issue.
But I'm also going to remove use of
org.keycloak.adapters.HttpClientBuilder from our apps code to make it
more stable for future changes.
Hope use of plain HttpClient without the keycloak builder will work OK.
Thanks
Vlastimil
On 22.5.2015 15:15, Marko Strukelj wrote:
----- Original Message -----
> Hi,
>
> On 22.5.2015 14:36, Marko Strukelj wrote:
>> @Vlastimil - a few questions:
>>
>> Do you use org.keycloak.adapters.HttpClientBuilder in your app?
> yes, colleague (in CC) who create the code used some example how to call
> Keycloak REST API from java code, so he uses this
Ok, in this case you have to make sure to include jboss-deployment-structure.xml that
adds dependency on org.apache.httpcomponents. To make sure you use the right slot, open
the modules/org/keycloak/keycloak-adapter-core/main/module.xml (could be in
modules/system/layers/base). In that file find dependency on org.apache.httpcomponents and
check if it has a slot="4.3".
In your jboss-deployment-structure.xml you have to use the same dependency. That's
all. Things should then work.
Or another option that Stian suggested ... don't use HttpClientBuilder at all. Forget
about it. Use HttpClient directly. I think in that case it's up to you how you provide
HttpClient to your .war. Haven't yet tried though. That one is on TODOs ...
>> Do you import any other class from org.keycloak.adapters in your app?
> no
>> Do you package httpclient.jar within your .war by any chance?
> no
>> 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>
> Yes. I tried this both with and without slot="4.3" attribute but error
> is here in both cases.
>
One of these cases should be a solution to your problem.
> A bit strange thing is that LinkageError has been thrown in finally
> block on call of
> client.getConnectionManager().shutdown();
>
> When I commented this out then LinkageError arrised at line with
> HttpResponse response = client.execute(get);
> call, which is still not first occurence of httpclient in the method,
> but I understand that it is classloading problem which is always strange ;-)
Sounds like there is more going on here than what I initially described. There might be
more ways of erroneous interaction between multiple versions of HttpClient than we
currently see.
If you could make a reproducer and add it to JIRA that would be great ... as I'm a
bit in the dark here now.
It could be related to this issue: https://issues.jboss.org/browse/KEYCLOAK-1338
- m
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
5:17 a.m.
There's a proposed fix for addressing this in our example demos:
https://github.com/keycloak/keycloak/pull/1276
With this patch customer-portal, product-portal and other demos always use whatever
httpcomponents version is packaged with AS7 / Wildfly without any collision with
Keycloak.
----- Original Message -----
Hi Marko,
thanks, I'll try to prepare reproducer project and attach it to the issue.
But I'm also going to remove use of
org.keycloak.adapters.HttpClientBuilder from our apps code to make it
more stable for future changes.
Hope use of plain HttpClient without the keycloak builder will work OK.
Thanks
Vlastimil
On 22.5.2015 15:15, Marko Strukelj wrote:
> ----- Original Message -----
>> Hi,
>>
>> On 22.5.2015 14:36, Marko Strukelj wrote:
>>> @Vlastimil - a few questions:
>>>
>>> Do you use org.keycloak.adapters.HttpClientBuilder in your app?
>> yes, colleague (in CC) who create the code used some example how to call
>> Keycloak REST API from java code, so he uses this
> Ok, in this case you have to make sure to include
> jboss-deployment-structure.xml that adds dependency on
> org.apache.httpcomponents. To make sure you use the right slot, open the
> modules/org/keycloak/keycloak-adapter-core/main/module.xml (could be in
> modules/system/layers/base). In that file find dependency on
> org.apache.httpcomponents and check if it has a slot="4.3".
> In your jboss-deployment-structure.xml you have to use the same dependency.
> That's all. Things should then work.
>
> Or another option that Stian suggested ... don't use HttpClientBuilder at
> all. Forget about it. Use HttpClient directly. I think in that case it's
> up to you how you provide HttpClient to your .war. Haven't yet tried
> though. That one is on TODOs ...
>
>
>>> Do you import any other class from org.keycloak.adapters in your app?
>> no
>>> Do you package httpclient.jar within your .war by any chance?
>> no
>>> 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>
>> Yes. I tried this both with and without slot="4.3" attribute but
error
>> is here in both cases.
>>
> One of these cases should be a solution to your problem.
>
>> A bit strange thing is that LinkageError has been thrown in finally
>> block on call of
>> client.getConnectionManager().shutdown();
>>
>> When I commented this out then LinkageError arrised at line with
>> HttpResponse response = client.execute(get);
>> call, which is still not first occurence of httpclient in the method,
>> but I understand that it is classloading problem which is always strange
>> ;-)
> Sounds like there is more going on here than what I initially described.
> There might be more ways of erroneous interaction between multiple
> versions of HttpClient than we currently see.
> If you could make a reproducer and add it to JIRA that would be great ...
> as I'm a bit in the dark here now.
>
> It could be related to this issue:
> https://issues.jboss.org/browse/KEYCLOAK-1338
>
> - m
--
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team
4000
days inactive
4004
days old
16 comments
5 participants
participants (5)
-
Marek Posolda -
Marko Strukelj -
Stan Silvert -
Stian Thorgersen -
Vlastimil Elias