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

[David M. Lloyd]

On 05/05/2011 10:49 AM, David Bosschaert wrote:
> 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.

I don't know if OSGi is compatible with security managers, but this also 
has the added annoyance of potentially requiring privileged blocks in 
this case.

> 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...

I like (c) better as well - I agree, doing both would be nicest.
-- 
- DML