I think Sanne's idea was that you shouldn't have to specify the class or class loader on every get, as it's very likely that all operations on that cache will use the same classloader. Most applications will only use one classloader anyway.
I'm not even sure we should allow using more than one classloader, otherwise a get operation might return an object loaded from the wrong classloader. After all, we will only use the provided classloader if we need to get the object from another node or if storeAsBinary is set to true. Dan On Mon, May 2, 2011 at 11:24 PM, Thomas P. Fuller <thomas.ful...@coherentlogic.com> wrote: > How about just using "as" and "using" instead of "asClass" and > "usingClassloader"? > > Consider something like the following which kind of looks like a dsl: > > Foo f = cache.getAdvancedCache().as (Foo.class).using (classLoader).get > (key); > > T > > ________________________________ > From: Sanne Grinovero <sanne.grinov...@gmail.com> > To: infinispan -Dev List <infinispan-dev@lists.jboss.org> > Sent: Mon, 2 May, 2011 21:08:47 > Subject: Re: [infinispan-dev] [Pull Request] Modular Classloading > Compatibility > > 2011/5/2 Manik Surtani <ma...@jboss.org>: >> >> On 1 May 2011, at 13:38, Pete Muir wrote: >> >>>>> As in, user API? That's a little intrusive... e.g., put(K, V, cl) ? >>>> >>>> Not for put, since you have the class, just get, and I was thinking >>>> something more like: >>>> >>>> Foo foo = getUsing(key, Foo.class) >>> >>> This would be a pretty useful addition to the API anyway to avoid user >>> casts. >> >> Maybe as an "advanced" API, so as not to pollute the basic API? A bit >> like: >> >> Foo f = cache.getAdvancedCache().asClass(Foo.class).get(key); > > doesn't look much better than a cast, but is more cryptical :) > > getting back to the classloader issue, what about: > > Cache c = cacheManager.getCache( cacheName, classLoader ); > > or > Cache c = cacheManager.getCache( cacheName ).usingClassLoader(classLoader ); > > BTW if that's an issue on the API, maybe you should propose it to > JSR-107 as well ? > > Sanne > > _______________________________________________ > 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