On 16 May 2011, at 18:20, Galder Zamarreño wrote: > > On May 12, 2011, at 11:18 AM, Dan Berindei wrote: > >> On Wed, May 11, 2011 at 11:18 PM, David Bosschaert <da...@redhat.com> wrote: >>> On 11/05/2011 17:54, Dan Berindei wrote: >>>> On Wed, May 11, 2011 at 7:08 PM, Pete Muir<pm...@redhat.com> wrote: >>>>> Were we developing for OSGi I would certainly agree with you. However in >>>>> many environments today we can reasonably expect the TCCL to be set and >>>>> to be able to load the classes we need. So whilst making it part of the >>>>> API is the safest option, it's also making complicated an API for the >>>>> sake of the few at the cost of the many. Further this also seems kinda >>>>> nasty to me. We know the class (and hence bundle/module) when we put the >>>>> object into Infinispan, therefore why do we require people to respecify >>>>> this again? >>>>> >>>>> David, can we not actually do something here akin to what we are >>>>> discussing for Weld? Whereby we can serialize out the bundle id and then >>>>> find the correct CL based on that when we deserialize. >>>> What if the object is a java.util.ArrayList? Each element in the list >>>> could belong to a different bundle, so you'd have to write a bundle id >>>> for every element in the list. >>> Yes, if you know the Bundle-SymbolicName and Version (or the Bundle ID) >>> you can find its classloader. >>> >>> On the other question, if you're passing in a class object then you can >>> obtain its classloader and hence the bundle where it came from. But, and >>> I think this is what Dan allused to above, is it always true that the >>> class your passing in comes from the bundle that you need to have or >>> could it also come from one of its parent class loaders? >>> >> >> Exactly David, sorry if my message was a little cryptic. I think in >> order to handle every case properly you would have to go through the >> entire object graph being stored in the cache in order to find all the >> classloaders/bundle ids that you will need on get(). >> >> That seems like a lot of overhead to me, and forcing the user to >> provide the classloader doesn't seem that bad in comparison. Perhaps >> we should use something other than a thread-local for this though, so >> that users can do a onto the result of a >> cacheManager.getCache("A").usingClassLoader(A.class) and never have to >> provide the classloader again. >> >> In fact I think this is a good idea for the invocation flags we >> already have, too. It would involve creating lots of overloads in >> CacheDelegate with a PreInvocationContext parameter and a new >> CacheDelegateWithContext class to invoke those methods, but the public >> API would remain the same. > > No matter how I look at it, putting a classloader in a thread local makes me > shiver.
I also wonder why we want do this, given we already have a construct called the Thread Local Context Classloader ;-) Either we use that, or use some other mechanism. > Just imagine the mayhem you can cause if you "forget" to clear the thread > local. > > I've done enough of Apache Commons Logging support to understand that you > should limit the references to classloaders to the minimum, particularly in > system classes/infrastructure. > > If we need to end up forcing users to register classloaders in these > scenarions, we need to do it in such way that either: > > - we can detect these leaks (it might be a bit primitive now but old JBoss > JCA code had an interesting way of discovering unclosed open connections) > > - if we give you on trying to detect them, the impact of a leak is reduced as > much as possible. > > Cheers, > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev