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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev