Bug #516684 has shown a problem with the new class loading model that is related to caching of class data at the JVM level. The problem is due to the fact that all mbean services execute with the same MBeanClassLoader instance. Here is the scenario in Bug #516684
1. A sar containing an mbean service and an ejb-jar is deployed. The mbean service references home and remote interfaces from the ejb-jar. 2. The home and remote interfaces are loaded into the ServiceLibraries repository by the ejb-jar class loader. 3. The mbean service is executed and it uses its thread context class loader to access the ejb home and remote interfaces. The MBeanClassLoader obtains these from the ServiceLibraries repository. However, the JVM believes that it is the MBeanClassLoader which loaded these classes and creates a cache record from the MBeanClassLoader to the ejb home interface. This is invalid because the on redeployment another ejb-jar class loader will be the source of the update ejb home. The solution is to execute mbean services with the thread context class loader set to the class loader created to load the deployment unit the mbean was in. I do not think we have this capability currently because we are using Sun jmxri implementation, but I need to look into this further. It is a point to remember for our jmx implementation. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
