[jboss-dev-forums] [Design of JBossCache] - Re: Default classloader for deserialization

[scott.stark@jboss.org]

"bstansberry at jboss.com" wrote : 
  | Problem with this is it requires an integration layer to register the classloader, manage the lifecycle, etc.  It's also built around an assumption that different regions of the cache use different classloaders.  Overly complex and painful for a simple ear that wants to deploy a cache from the ear and use it.
  | 
  | It would be nice to make it easy for a user to specify during the configuration stage that the TCCL should be registered as the classloader for the entire cache and that the ordinary create/destroy lifecycle methods should deal with the classloader.
  | 
To me this is another wrapper that integrates well with this usage. Its an mbean service/mc bean that performs the same deployment level integration as the other jboss cache based aspects. This is an independent distributed cache usage outside of any ejb3/hibernate/session usage?

I guess I'm not clear on what the point of this thread is. The only concern it raises is that if we are promoting indpendent use of jboss cache, it leads to an obvious conflict of versions when an ear is trying to deploy a version of jboss cache that differs from that bundled with the server. This either requires obfuscation of the package names or very careful control of the container class loading setup.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989454#3989454

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989454