On Thu, May 12, 2011 at 1:22 PM, Emmanuel Bernard <emman...@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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev