Supporting XBean services within the GBean kernel

[James Strachan]

I fell for the charms of XBean a long time ago; both ActiveMQ and ServiceMix have been using it as its primary configuration mechanism for some time. I recently XBean-ified Jetty too which took about an hour and can currently configure most of Jetty. Incidentally there's currently a real simple file system based deployer that can walk the file system building up classpath trees and booting up any XBean or Spring applications it finds. e.g. the following test repository boots up ActiveMQ fully configured via XBean. (This deployer could use some work to be able to deal with service and classpath dependencies, to allow graphs rather than just trees to be used)
http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-server/src/test/repository/

The GBean integration of ActiveMQ has always been pretty simple and limited; I"ve always wanted full rich integration where every single transport connector, network connector, journal configuration, thread pool, queue, topic, connection & subscription are all richly available to the GBean kernel & management subsystem etc. We kinda have that today with a combination of XBean and JMX; but it doesn't really integrate yet with the GBean kernel.

So I'm wondering if we can put together some kind of GBean facade to XBean; so the current kernel sees the XBean world as just a bunch of GBeans and anything which can deploy in XBean (which includes pretty much every Spring application on the planet) suddenly becomes available nicely into the GBean world.

Something like a GBean which boots up the XBean kernel and exposes all the registered services as GBeans would do the trick. It shouldn't be too hard right?

A second question is; what to do about JMX. In ActiveMQ we've written a bunch of MBeans so whether you use ActiveMQ in J2SE or J2EE you can point JConsole at the JVM and see all the various stats, queue depths, buffer sizes and so forth. Some of these things are created at deployment time; though most of them come and go as clients connect to the broker and the brokers own runtime state changes e.g. deach connection & subscription has an MBean; clients can create new destinations at runtime etc. How would it be best to integrate those into the GBean infrastructure - or would it be best to just leave them in JMX and let the management portlets just use JMX to access them.

--

James
-------
http://radio.weblogs.com/0112098/