this is due to the fact that objects in the cache that is residing in the same JVM as the ejb are accessed by reference without any check whether the previous loaded classes of these objects are accessible to the current ejb's classloader anymore. This isn't easy to solve as long the objects themselve are stored in the cache and not externalized or serialized versions of them.
I'd expect you would get the same error if you deploy two ejbs accessing the same instance of TreeCache from 2 different ears using classes that are both loaded by the different classloaders of the 2 applications. Flushing the local cache on undeployment of the ejb is not a solution, since this might lead to totally unexpected behavior (as it makes a difference wheter another member in the group is active until the ejb is redeployed which would allow to refetch the state.) As a workaround you may include the classes in the servers classpath, so the classes do not have to be reloaded. Maybe this is the only suitable solution as long we agree that it's desirable to allow a per-JVM shared cache at all. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3846757#3846757 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3846757 ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
