I'm not sure this is all that is happening. I've just committed a test
case (org.jboss.test.jmx.test.MBeanClassLoaderUnitTestCase) that shows that
an mbean instance thinks it's classloader is a UnifiedClassLoader, and that
when you redeploy the classes (and mbeans), the UnifiedClassLoader changes
appropriately.
here's some test log: A and B are mbeans based on the same class, and are
deployed and redeployed.
[MBeanClassLoaderUnitTestCase,DEBUG] classloader for A: JBoss
UnifiedClassloader: keyURL :
file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/68.testmbeanclassloader.jar]
[MBeanClassLoaderUnitTestCase,DEBUG] classloader for B: JBoss
UnifiedClassloader: keyURL :
file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/68.testmbeanclassloader.jar]
[MBeanClassLoaderUnitTestCase,DEBUG] classloader for A: JBoss
UnifiedClassloader: keyURL :
file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/70.testmbeanclassloader.jar]
[MBeanClassLoaderUnitTestCase,DEBUG] classloader for B: JBoss
UnifiedClassloader: keyURL :
file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/70.testmbeanclassloader.jar]
The values we see are from:
public String getClassLoader()
{
return this.getClass().getClassLoader().toString();
}
I think this is rather odd because the ServiceCreator asked the MBeanServer
to create the mbean using an MBeanClassLoader instance created specifically
for each mbean instance.
create and register the MBeanClassLoader:
ObjectName loader = new ObjectName("jboss.system.classloader:id=" +
name.hashCode());
MBeanClassLoader cl = new MBeanClassLoader(name);
if (!server.isRegistered(loader))
server.registerMBean(cl, loader);
and
create the MBean itself.
ObjectInstance instance = server.createMBean(code,
name,
loader,
constructor.params,
constructor.signature);
Why doesn't the mbean think its classloader is an MBeanClassLoader?
What's going on?
david jencks
On 2002.02.17 19:40:08 -0500 Scott M Stark wrote:
> 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
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
