[infinispan-dev] [Pull Request] Modular Classloading Compatibility

[Pete Muir]

Galder commented this on Github, which I think the answer to deserves a wider audience:

>> @@ -155,9 +155,9 @@ public class ConfigFilesConvertor {
>>       }
>> 
>>       if (type.equals(JBOSS_CACHE3X)) {
>> -         transformFromJbossCache3x(sourceName, destinationName);
>> +         transformFromJbossCache3x(sourceName, destinationName, ConfigFilesConvertor.class.getClassLoader());

Actually this is a bug, I can just pass null here (see below).

> 
> Just a question to clarify my understanding: So here since the XSLT to load comes from us, we simply use our own cache loader cos the file should be there. For any classes that are loaded coming potentially from the user, use TCCL, right?


If we know a class/resource comes from an Infinispan jar, then it must be on the same classloader as the class we are currently loading from, so we definitely know the classloader (it's the one used to load us).

For any classes that may come from the application, we need to use the app classloader. In a traditional Java EE env, this is the TCCL, however outside of such an environment, the TCCL may well not be set, so we need to know about the app classloader in some other way. This is where it get's tricky ;-)

The classloader lookup I have gone with in Infinispan is:

* If a (app) classloader is passed in, look here,
* If the class is not found in the app classloader (either not visible or no app classloader) look on the Infinispan classloader
* Otherwise, look on the system classloader (some comment about agent based instrumentation means we apparently need this)

At the moment, I have always passed in the TCCL as the app classloader at the "furthest out" point that I can reach, and I now need to go through the code base and remove all refs to the TCCL, using (a), (b), (c) below.

On 8 Jun 2011, at 14:13, Manik Surtani wrote:

> 
> On 8 Jun 2011, at 14:06, Pete Muir wrote:
> 
>> We've decided that rather than swap out the TCCL (which is frankly a bit error prone), to fix this properly and have it so that each time a class is loaded it must select the classloaders it wants. To help, we will add an advancedCache.getClassLoader(), which defaults to the TCCL but can be overridden as described below.
>> 
>> As a first step, I have removed the TCCL from the default lookup in Util (AFAICT all class loading was going through there), and required that, if you want to lookup app classes (as opposed to Infinispan classes) you explicitly pass in a classloader. I have then passed in the TCCL as a parameter throughout the codebase. This now makes it explicit where the TCCL is being used and should mean that any new work does think about whether they need to look at app classes or not.
>> 
>> Under this new scheme we have 45 refs to the TCCL in the codebase. Some of these are:
>> 
>> a) not needed, we are only ever loading system classes
>> b) can, with a bit of a refactor, refer to the classloader we select using withClassLoader()
>> c) other (these will be harder to fix :-()
>> 
>> My plan is to go through each one, and chat with the owner of the code and discuss which of (a), (b) or (c) is relevant here.
> 
> Sounds good.
> 
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
> 
> Lead, Infinispan
> http://www.infinispan.org
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev