Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
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.fuller(a)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.grinovero(a)gmail.com>
To: infinispan -Dev List <infinispan-dev(a)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 <manik(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev