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

On 05/05/2011 10:55, Pete Muir wrote: > I talked about this with Emmanuel last night, and we were > > a) concerned about the pollution of the API that this implies > b) not sure why we need to do this > > So I also spoke to Jason to understand his initial motivation, and from this chat I think it's clear that things have gone off course here. > > Jason raised two issues with modularity/classloading in Infinispan: > > 1) Using the TCCL as the classloader to load Infinispan classes is a bad idea. Instead we should use org.infinispan.foo.Bar.getClass().getClassLoader(). > > 2) When we need to load application classes we need a different approach to that used today. Most of the time the TCCL is perfect for this. However *sometimes* Infinispan may be invoked outside of the application, when the TCCL may not be set in AS7. Jason and I discussed three options: > > a) require (through a platform integration documentation contract) that the TCCL must always be set when Infinispan is invoked. > b) Have some sort of InvocationContext which knows what the correct classloader to use is (aka Hibernate/Seam/Weld design where there is a per-application construct based on a ThreadLocal). Given this hasn't been designed into the core, it seems like a large retrofit > c) Make users specify the CL (directly or indirectly) via the API (as we discussed). > > Personally I think that (a) is the best approach right now, and is not that onerous a requirement. > > We might want to make the TCCL usage pluggable for OSGI envs. Cc'd David to get his feedback. In a sense a) and c) are similar. The only difference is the way you provide the classloader. OSGi doesn't specify the value of the Thread Context Classloader, primarily because it allows the creation of threads in your own code so OSGi can't control the value of the TCCL in those threads. a) Would be okay for OSGi as long as it's clearly documented. People would have to write code to set the TCCL before they call infinispan and then unset if afterwards. It requires a try/finally block which isn't fun to write and its a little verbose, but you can do it.

c) Would be more user-friendly to OSGi users. It's easy to obtain the classloader of a bundle in OSGi so passing that in would be nice and easy. I guess you could consider providing both a) and c) at the same time, c) being simply an additional overload on the APIs so that people can choose whichever option they like best...