This is a different issue I'll look into as I get into the mbean behavior.
The issue with Bug #516684 is not that the same classloader is used
to load the original and redeployed mbean. This changes as you say.
The problem is that the classloader used as the thread context classloader
for mbean operation invocations is the same classloader across all
mbeans. This will be a problem when MarshalledObjects are unserialized
because, in the absence of security manger that allows for dynamic
class loading, the thread context classloader is used. Its not sufficient
to load the mbean with a unique classloader, this classloader also
needs to be established as the thread context classloader.
----- Original Message -----
From: "David Jencks" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, February 17, 2002 6:30 PM
Subject: Re: [JBoss-dev] A problem with the new class loading model
> 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.0b
eta/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.0b
eta/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.0b
eta/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.0b
eta/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
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
