No, because the RI does not understand our classloading.
It might work if you defined the MBeanServerBuilder class as a system
property before starting the jvm.
But then you would have to change the logic in
It works :-)
JMImplementation name=Default,service=LoaderRepository type=MBeanRegistry type=MBeanServerDelegate java.lang name=Code Cache,type=MemoryPool name=CodeCacheManager,type=MemoryManager name=Copy,type=GarbageCollector name=Eden Space,type=MemoryPool name=MarkSweepCompact,type=GarbageCollector name=Perm Gen,type=MemoryPool name=Survivor Space,type=MemoryPool name=Tenured Gen,type=MemoryPool type=ClassLoading type=Compilation type=Memory type=OperatingSystem type=Runtime type=Threading java.util.logging type=Logging jboss database=localDB,service=Hypersonic name=PropertyEditorManager,type=Service ...
And you will want to check the performance of that thing.
That was the main reason for having to rewrite it.
You mean the MBeanServer? We use our MX implementation so there is no issue there.
Now, what overhead those MXBeans impose that I don't know, but they must be integrated with the underlying JVM in a native way probably.
A couple of glitches I noticed:
To activate/integrate with this, you need to let them (ManagementFactory.getPlatformMBeanServer()) create the MBeanServer (they'll use the initial 'builder' setting so we still get our own JMX impl), and then we use this as our main MBeanServer.
It doesn't work the other way around i.e. provide them with an existing MBeanServer to use (which is stupid). Also, while the docs say it'll use "DefaultDomain" for this MBeanServer, apparently 'null' is used as the default domain (this must be a bug). Again, this should be settable.
So we loose "jboss" being the default domain, but that's not too bad, with a little twiking of the MBeanServerLocator.locateJBoss() (as Adrian noted) we can locate the main jboss MBeanServer not necessarily by name (well, we could look for 'null') but instead store a reference to it at instantiation time, which is probably more correct, since we could have many "jboss" MBeanServers...
Another strange thing, although it instantiates you own JMX MBeanServer implementation, it hijacks the javax.management.MBeanServerDelegate to show 'Sun' as being the ImplementationVendor, generating it's own MBeanServerId (did we have some code that depended on the id format/uniqueness???)
But wait! I just checked, this happens anyway it you run under jdk5, I hadn't noticed it before...
In any case, it looks pretty cool on the jmx-console to get all this metrics about the garbage collector, etc. and it opens up new possibilities for setting up all sorts of monitors.
I think I'll commit this to head so you can have look (the change is pretty minor), so when jboss starts under jdk5 it'll instantiate those MXBeans, and I'll use also a system property to turn off this, if needed (or the ther way round? :)
Was this ever put in? Does it exist in 4.0.2?
If so, how do you turn this on. I would like to see the standard java JMX beans in the jmx-console.
This is the design forums. If you want to ask for help, use the user forums!!!!
If you want to know what is in a release, use the release notes.
The JBoss forums are not a mechanism whereby you can get every frivilous
question answered without doing some research for yourself.
Following up on http://jira.jboss.com/jira/browse/JBAS-1610
The issue is that to start the agent for jconsole "-Dcom.sun.management.jmxremote"
we must have JBossJMX in the CLASSPATH rather than having ServerImpl
setup the system properties and classloader.
We cannot use Sun's MBeanServer because
1) We cannot plugin our UnifiedLoaderRepository
2) It does not do MBean context classloading
3) It is slow for Standard/ModelMBean (see the performance tests in the jmx module)
In fact when we did use Sun's MBeanServer in 2.4.x we had to implement performance
critical mbeans like the EJBContainer using DynamicMBeans.
1) Write a listener for MBeanRegistration events that creates proxies from
the platform mbean server to the JBoss MBeanServer (a poor man's cascading MBeanServer)
2) Deploy a jmx remote connector in JBoss's MBeanServer and use the remote tab
to connect to it from jconsole (including adding the platform XMBeans to JBoss's MBeanServer).
I think a new jmx remote connector is what we really need, because even with the current workaround, there are still the problems of accessing objects that are not really designed for remote access.
We need a flexible connector that can be configured for remote class loading and even custom serialization/object replacement of non-remotable objects. I would have looked at this first but I was not sure how far Tom has gotten with the current implementation.
We might be able to do something with the extension points
I'm not that familiar with JSR160
Another workaround I was using, is to explicitly set the jboss classpath and the mbeanserver builder in a batch file (like what Main and ServerLoader would do), so only one mbeanserver gets created (the platform one).
I've added that as a subtask to the case: