|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.
right,
|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.
Oh come on. You didn't implement an implicit way of doing class tracking,
you did an xml based explicit one (and then partial since it was only for
SARs xml).
Ok seriously... What I think we can do better is the tracking for anything
that is out there with the new UCL since we DO have a unified classloader
for our universe now (it wasn't the case the first time I wrote the MCL).
So I need to look at it in the new light and try to do complete class
tracking implicitely. I will try to do good on working just from the UCL.
Your help in making it work will be much appreciated I think we can do
something quite interesting there, just give me a couple of days to climb on
top of my jetlag and my todo list for the next days. I will work on this
next week. (along with client interceptors and DR1)
marcf
|
|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/jbo
|ss-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/jbo
|ss-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/jbo
|ss-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/jbo
|ss-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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
