What about simply wrapping the call in your provider that triggers
third party loading the configuration with the TCCL wrapping code
like:

ClassLoader old = Thread.currentThread().getContextClassLoader();
try {
    Thread.currentThread().setContextClassLoader(getClass().getClassLoader());

    callThirdPartyLibrary();

} finally {
    if (old != null) {
        Thread.currentThread().getContextClassLoader(old);
    }
}

If third party library only loads its files at init time, then one
time call from within ProviderFactory init() should be enough, and
other invocations should not require the TCCL wrapping code.

On Tue, Jan 12, 2016 at 9:02 AM, Stian Thorgersen <sthorger@redhat.com> wrote:
> The problem is in the library you're using as it shouldn't be using the
> Thread.currentThread().getContextClassLoader(). It should use
> getClass().getResource or getClass().getClassLoader(). Is there a way around
> it?
>
> On 11 January 2016 at 23:24, Josh Cain <josh.cain@redhat.com> wrote:
>>
>> Hi all,
>>
>> I'm in the process of writing an SPI for a federation provider that relies
>> on a third party library, and the library in turn uses a number of files.  I
>> placed my SPI .jar, the third party library .jar, as well as its required
>> files in the keycloak-1.7.0.Final/standalone/configuration/providers
>> directory.  However, when the third party library attempts to locate its
>> required files on the classpath, it cannot find them.
>>
>> Just for a sanity check, I've placed the files places like the
>> sun/jdk/main module on the AS, and observed that the files were picked up
>> properly since that particular folder was on the classpath.
>>
>> Can anyone help me understand why those files are not being picked up as
>> classpath resources?  Does the configuration/providers directory not get
>> added to the classpath?
>>
>> Just FYI, I poked through the library a bit, and it doesn't seem to be
>> doing anything strange.  It winds up doing the equivalent of:
>>
>>
>> Thread.currentThread().getContextClassLoader().getResourceAsStream(filePath);
>>
>> Josh Cain | Software Applications Engineer
>> Identity and Access Management
>> Red Hat
>> +1 843-737-1735
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev