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

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