|
|The MLet class should not need the MBeanServer created before it so
|I think simply changing Main.java
|
|from:
| // Create MBeanServer
| final MBeanServer server = MBeanServerFactory.createMBeanServer();
| ...
| // Create MLet
| MLet mlet = new MLet(urls);
| server.registerMBean(mlet, new
|ObjectName(server.getDefaultDomain(), "service", "MLet"));
|
| // Set MLet as classloader for this app
| Thread.currentThread().setContextClassLoader(mlet);
|
|to this:
| // Create MLet
| MLet mlet = new MLet(urls);
| // Set MLet as classloader for this app
| Thread.currentThread().setContextClassLoader(mlet);
| // Create MBeanServer
| final MBeanServer server = MBeanServerFactory.createMBeanServer();
| server.registerMBean(mlet, new
|ObjectName(server.getDefaultDomain(), "service", "MLet"));
|
|will result in the MBeanServer implementation being loaded by the
|JBoss server
|class loader. The com.sun.management.jmx.MBeanServerImpl class is using
|its ClassLoader to locate classes rather the then context class loader:
|
| /**
| * Gets the class for the specified class name
| */
| private Class findClass(String className)
| throws ClassNotFoundException {
|
| Class theClass = null;
| ClassLoader myLoader = this.getClass().getClassLoader();
| if (myLoader != null) {
| theClass = myLoader.loadClass(className);
| } else {
| theClass = Class.forName(className);
| }
| return theClass;
| }
riiiigght....
the idea of "test the domain *name*" doesn't sound soo bad after all.
The reason is that it is a simple place to define the integration (by
scoping your domain in JBoss's). Therefore JBoss will assume that you are
"JBoss" aware and that your management is in place... working on String will
for sure be safe :)
hehe, I guess the second solution will have its problems too. That is when
you know your codebase is too big, a simple change triggers hell
marc
|
|----- Original Message -----
|From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
|To: <[EMAIL PROTECTED]>
|Sent: Wednesday, April 11, 2001 7:30 PM
|Subject: RE: [JBoss-dev] Nested JMX Service Groups...??!
|
|
|> Oh-oh,
|>
|> Classloaders. So I happely planned my night to add those two
|lines and go
|> out with friends but then I realized how deep the rabbit hole goes.
|>
|> I was stunned to realize that:
|>
|> server.isInstanceOf(mbeanName,"org.jboss.util.Service") always returns
|> false and here is why.
|>
|> MBeanServerImpl implementation of this method obviously has to load our
|> service class to do type check. It uses classloader that loaded
|> MBeanServerImpl which in our case is AppClassLoader. AppClassLoader in
|> turn can't "see" any of our jboss classes since they were loaded with
|> Mlet.
|>
|> I can't see no way to tell to MBeanServer to use other
|classloader nor did
|> JMX engineers hooked wires for CCLs. So as soon ClassNotFoundException is
|> caught (inside MbeanServer.isInstanceOf) false is returnd :(
|>
|> Feedback?
|>
|> vlada
|>
|>
|> On Wed, 11 Apr 2001, marc fleury wrote:
|>
|> > Bla enough talk, add the f*cking line already
|> >
|> > ||I still don't see anything wrong with type check for
|> > ||org.jboss.util.Service.
|> > ||Vladimir
|> >
|> > "code with your balls on the keyboard"
|> >
|> > _______________________________________________
|> > Jboss-development mailing list
|> > [EMAIL PROTECTED]
|> > http://lists.sourceforge.net/lists/listinfo/jboss-development
|> >
|>
|>
|> _______________________________________________
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> http://lists.sourceforge.net/lists/listinfo/jboss-development
|>
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
