<div dir="ltr"><div>Sounds good, thanks for pointing that out Stian and Marko. Might work through a little wrapping code now, but should be able to work with the lib authors to get that changed.<br><br></div>Appreciate the help!<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><span><div><div>Josh Cain | Software Applications Engineer<br></div><i>Identity and Access Management</i><br></div><b>Red Hat</b><br>+1 843-737-1735<br></span></div></div></div>
<br><div class="gmail_quote">On Tue, Jan 12, 2016 at 3:55 AM, Marko Strukelj <span dir="ltr"><<a href="mailto:mstrukel@redhat.com" target="_blank">mstrukel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What about simply wrapping the call in your provider that triggers<br>
third party loading the configuration with the TCCL wrapping code<br>
like:<br>
<br>
ClassLoader old = Thread.currentThread().getContextClassLoader();<br>
try {<br>
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());<br>
<br>
callThirdPartyLibrary();<br>
<br>
} finally {<br>
if (old != null) {<br>
Thread.currentThread().getContextClassLoader(old);<br>
}<br>
}<br>
<br>
If third party library only loads its files at init time, then one<br>
time call from within ProviderFactory init() should be enough, and<br>
other invocations should not require the TCCL wrapping code.<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Jan 12, 2016 at 9:02 AM, Stian Thorgersen <<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>> wrote:<br>
> The problem is in the library you're using as it shouldn't be using the<br>
> Thread.currentThread().getContextClassLoader(). It should use<br>
> getClass().getResource or getClass().getClassLoader(). Is there a way around<br>
> it?<br>
><br>
> On 11 January 2016 at 23:24, Josh Cain <<a href="mailto:josh.cain@redhat.com">josh.cain@redhat.com</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> I'm in the process of writing an SPI for a federation provider that relies<br>
>> on a third party library, and the library in turn uses a number of files. I<br>
>> placed my SPI .jar, the third party library .jar, as well as its required<br>
>> files in the keycloak-1.7.0.Final/standalone/configuration/providers<br>
>> directory. However, when the third party library attempts to locate its<br>
>> required files on the classpath, it cannot find them.<br>
>><br>
>> Just for a sanity check, I've placed the files places like the<br>
>> sun/jdk/main module on the AS, and observed that the files were picked up<br>
>> properly since that particular folder was on the classpath.<br>
>><br>
>> Can anyone help me understand why those files are not being picked up as<br>
>> classpath resources? Does the configuration/providers directory not get<br>
>> added to the classpath?<br>
>><br>
>> Just FYI, I poked through the library a bit, and it doesn't seem to be<br>
>> doing anything strange. It winds up doing the equivalent of:<br>
>><br>
>><br>
>> Thread.currentThread().getContextClassLoader().getResourceAsStream(filePath);<br>
>><br>
>> Josh Cain | Software Applications Engineer<br>
>> Identity and Access Management<br>
>> Red Hat<br>
>> <a href="tel:%2B1%20843-737-1735" value="+18437371735">+1 843-737-1735</a><br>
>><br>
>> _______________________________________________<br>
>> keycloak-dev mailing list<br>
>> <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> keycloak-dev mailing list<br>
> <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</div></div></blockquote></div><br></div>