<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 5/22/2015 3:50 AM, Marko Strukelj
wrote:<br>
</div>
<blockquote
cite="mid:1329091490.2956540.1432281027019.JavaMail.zimbra@redhat.com"
type="cite">
<div style="font-family: times new roman, new york, times, serif;
font-size: 12pt; color: #000000">
<div>I like Stian's solution much better ... it's much simpler
:)</div>
</div>
</blockquote>
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."<br>
<blockquote
cite="mid:1329091490.2956540.1432281027019.JavaMail.zimbra@redhat.com"
type="cite">
<div style="font-family: times new roman, new york, times, serif;
font-size: 12pt; color: #000000">
<div><br>
</div>
<div>@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
... </div>
<div><br>
</div>
<div>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 ...</div>
<div>Or maybe we have one single module that's client API?</div>
<div><br>
</div>
<div><br>
</div>
<hr id="zwchr">
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<div class="moz-cite-prefix">On 5/21/2015 4:56 PM, Marko
Strukelj wrote:<br>
</div>
<blockquote
cite="mid:60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com">
<pre>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?</pre>
</blockquote>
What do I think? I think that classloading questions always
make my head hurt!<br>
<br>
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.<br>
<br>
It should be possible, but I don't know if it actually <span
data-mce-style="text-decoration: underline;"
style="text-decoration: underline;">IS</span> 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. :-)<br>
<blockquote
cite="mid:60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com">
<pre>
_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></blockquote>
<div><br>
</div>
</div>
</blockquote>
<br>
</body>
</html>