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

[Jason T. Greene]

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. 
If it's a class that is just internal wiring of infinispan, then 
Infinispan's defining classloader should always be used.

The one case I can think of in infnispan where TCCL really makes sense 
is in the case of lazy deserialization from an EE application. However 
that is only guaranteed to work when you are executing in a context that 
has that style of contract (like in an EE component). There are many 
other cases though where someone would expect it to work from a non-EE 
context (e.g. from a thread pool). What you really want is the caller's 
classloader, but that is not cheap to get at, so it's something that 
should be supplied as part of the API interaction (in the case where 
there is no EE context). Alternatively you can just just require that 
folks push/pop TCCL, but users often get this wrong.

Thanks!

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