On 2002.02.20 20:10:35 -0500 marc fleury wrote:
>
> |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).
>
I didn't mean to imply that I don't agree that the mbeanclassloader way is
better. I just didn't think of it or implement it. I think it's better.
> 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)
good. Looking forward to it. I'm not at all convinced we understand what
is really going on behind the bug that started this.
david jencks
btw, welcome back!!
>
> 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
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
