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

[Dan Berindei]

On Thu, May 12, 2011 at 1:22 PM, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:
>
> On 12 mai 2011, at 11:18, Dan Berindei wrote:
>
>> 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.
>
> Note that I don't think it works in the case you mentioned earlier ie a ArrayList with classes from many different bundles.
>

It works, only now it's the user's job to provide the right classloader.

I suspect most people will have the same situation as Augusto, the guy
who was asking about classloading rules on the forum
(http://community.jboss.org/message/602759): they already have a
bundle that has access to the classes that will ever be in the cache
(in Augusto's case via DynamicImport-Package: *), their only problem
is convincing Infinispan to use that bundle's classloader for
unmarshalling.

If they don't like the idea of having a catch-all bundle, they can
instead write a bridge classloader themselves that holds a list of
classloaders and loads classes from any of them. They can even write
the bundle ids in the cache if the list of bundles can only be
determined at runtime.

Of course, Augusto's bundles don't access each other's objects in the
cache, so his problem could also be solved by giving each bundle it's
own CacheDelegateWithContext (or CacheDelegateSession, if you will)
instance configured with that bundle's classloader, removing the need
for the DynamicImport-Package directive in his central bundle.

Cheers
Dan