What about a helper that just returns a cache with a specific classloader from a cache?
cache.withLoader(cl).get(K key) -a On Mon, May 16, 2011 at 11:14 AM, Galder Zamarreño <gal...@redhat.com>wrote: > > On May 16, 2011, at 7:57 PM, Sanne Grinovero wrote: > > > I don't like the TCCL either, so I'll repeat my suggestion from two > > weeks ago to just have: > > > > Cache c = cacheManager.getCache( cacheName, classLoader ); > > > > sounds reasonable to me to have the application declare it's intentions > once ? > > > > BTW I don't like > > > > "cache.get(K key, Class<V> clazz)" > > > > as we're not speaking only about the get(K) method, but about many > > methods and this will explode the number of method of Cache; on the > > other hand I think it;s acceptable to have a single Cache instance > > used by a single application/classloader. You can still have multiple > > applications share the same underlying cache and use different > > classloaders: > > Guys, we're going around in circles. As I said the other week, you can't > assume 1 cache = 1 classloader cos for example in the Hibernate 2LC all > entities will be stored in a single cache as opposed to today where we have > a cache per entity. And if all entities are stored in the same cache, we > potentially have a cache that contains data belonging to multiple cache > loaders. And the reason for all this is cos we don't support asymmetric > clusters. > > Could someone start a design wiki to grab all the requirements? > > > > > getCache( cacheName, classLoader ) would return a delegate to the > > original cache, having a specific marshaller in the invocation context > > as Trustin was suggesting. > > > > Cheers, > > Sanne > > > > > > 2011/5/16 Pete Muir <pm...@redhat.com>: > >> > >> 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 > >> > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > 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