Shouldn't MBeanClassLoader usage be replaced by UnifiedClassLoader ?
They appear to be very similar. Is there some special need to have
these separated?
--jason
On Sun, 2002-02-17 at 18:30, David Jencks wrote:
> 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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
