On May 18, 2011, at 6:06 PM, Manik Surtani wrote:
> Hi guys
>
> Sorry I've been absent from this thread for a while now (it's been growing
> faster than I've been able to deal with email backlog!)
>
> Anyway, this is a very interesting discussion. To summarise - as Pete did at
> some point - there are 2 goals here:
>
> 1. Safe and intuitive use of an appropriate classloader
> 2. Safe type system for return values.
>
> I think the far more pressing concern is (1) so I'd like to focus on that.
> If we think (2) is pressing enough a concern, we should spawn a separate
> thread and discuss there.
>
> So, onto the issue of safe classloading.
>
> 1) Class loader per session/cache.
>
> I like Jason/Sanne/Trustin's suggestions of a session-like contract, and
> specifically I think this is best achieved as a delegate to a cache, again as
> suggested elsewhere by Pete, etc. E.g.,
>
> Cache<?, ?> myCache = cacheManager.getCache("myCache", myClassLoader);
>
> and what is returned is something that delegates to the actual cache, making
> sure the TCCL is set and re-set appropriately. The handle to the cache is
> effectively your "session" and each webapp, etc in an EE environment will
> have its own handle. I propose using the TCCL as an internal implementation
> detail within this delegate, helps with making sure it is carefully managed
> and cleaned up while not re-engineering loads of internals.
>
> I think EmbeddedCacheManager.getCache(String name, ClassLoader cl) is enough
> ... it is clear enough, and I don't see the need for overloaded
> getCache(name, classOfWhichClassLoaderIWishToUse).
What about the unmarshalling part where a cache can be unmarshalled with
several classloaders? Assuming that the classloader you pass here is just part
of the handle, or the cache delegate, you still need storeAsBinary for
unmarshalling part, correct?
If you expect only one classloader to interact with the cache, you could do
away with storeAsBinary and get cache's associated classloader to deserialize
it.
Correct?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
