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

[Jason T. Greene]

On 4/28/11 4:52 PM, Manik Surtani wrote:
>
> On 27 Apr 2011, at 12:39, Jason T. Greene wrote:
>
>> Available here:
>> https://github.com/infinispan/infinispan/pull/278
>>
>> The problem is basically that infinispan currently is using TCCL for all
>> class loading and resource loading. This has a lot of problems in
>> modular containers (OSGi, AS7, etc), where you dont have framework
>> implementation classes on the same classloader as user classes (that is
>> how they achieve true isolation)
>>
>> You can read about this in more detail here:
>> http://community.jboss.org/wiki/ModuleCompatibleClassloadingGuide
>>
>> The patch in the pull request is a first step, and should fix many
>> issues, but it does not address all (there is still a lot of TCCL usage
>> spread out among cacheloaders and so on), and ultimately it's just a
>> work around. It should, however, be compatible in any other non-modular
>> environment.
>>
>> Really the ultimate solution is to setup a proper demarcation between
>> what the user is supposed to provide, and what is expected to be bundled
>> with infinispan. Whenever there is something the user can provide a
>> class, then the API should accept a classloader to load that class from.
>
> As in, user API?  That's a little intrusive... e.g., put(K, V, cl) ?

Not for put, since you have the class, just get, and I was thinking 
something more like:

Foo foo = getUsing(key, Foo.class)

This could verify type compatibility and use the classloader of the 
type. But that does of course mean more methods on AdvancedCache (not so 
great).

Alternatively you could just have a method on the invocation context. 
For friendlier interaction and elimination of thread locals, you could 
introduce a session based API.

CacheSession session = CacheSession.from(cache);
session.setClassLoader(blah);
session.setOtherInterestingOptionsLikeBatchingEtc

session.get/put etc

-- 
Jason T. Greene
JBoss, a division of Red Hat