[infinispan-dev] [Pull Request] Modular Classloading Compatibility

Dan Berindei dan.berindei at gmail.com
Wed May 4 09:55:52 EDT 2011


On Wed, May 4, 2011 at 7:18 AM, "이희승 (Trustin Lee)" <trustin at gmail.com> wrote:
> On 05/03/2011 09:33 PM, Sanne Grinovero wrote:
>> 2011/5/3 "이희승 (Trustin Lee)" <trustin at gmail.com>:
>>> On 05/03/2011 05:08 AM, Sanne Grinovero wrote:
>>>> 2011/5/2 Manik Surtani <manik at 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 ?
>>>
>>> We have a configurable Marshaller, right?  Then why don't we just use
>>> the class loader that the current Marshaller uses?
>>
>> +1
>> I like the clean approach, not sure how you configure the "current
>> Marshaller" to use the correct CL ?
>> Likely hard to do via configuration file :)
>
> By default, we could use the class loader that the current Unmarshaller
> uses, and let user choose a class loader for a certain get() call.
>
> So, we need to deal with the two issues here:
>
> 1) Make sure that user can configure the default class loader in runtime
> and calling get() (and consequently related unmarshaller) will use the
> default class loader:
>
>   cache.setDefaultClassLoader(UserClass.class.getClassLoader())
>
> 2) Provide an additional API that allows a user to specify a class
> loader for the current transaction or context:
>
>   cache.get(K key, Class<V> clazz) // +1 to Pete's suggestion
>

If V is Set<MyObject> then Set<MyObject>.class.getClassLoader() will
give you the system classloader, which in most cases won't be able the
MyObject class. It may not even be a Set<MyObject> of course, it could
be just Set<?>.

We could have a "shortcut" so the users can pass in a class instead of
a classloader to avoid writing ".getClassLoader()", but we shouldn't
require any relation between the class passed in and the class of the
return value.

Dan



More information about the infinispan-dev mailing list