On 2002.02.17 22:09:50 -0500 Jason Dillon wrote:
> Shouldn't MBeanClassLoader usage be replaced by UnifiedClassLoader ?
> They appear to be very similar. Is there some special need to have
> these separated?
>
> --jason
>
Well, I don't think so.
UnifiedClassLoader actually loads classes from URLs. MBeanClassLoader is
kind of a marker: there is one for each mbean instance. The idea, which is
not yet implemented, is that it should provide class <--> mbean dependency
tracking, so if the class of an mbean is undeployed without the mbean being
explicitly removed, the MBeanClassLoader sticks around as kind of a marker,
waiting for the class to show up again, then recreating the mbean instance.
This is, as I understand it, Marc's idea for a better way to do class <-->
mbean dependencies than the classpath dependency mechanism I once
implemented.
david jencks
>
> 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
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
