Thread: Re: [Springframework-developer] Spring & JMX

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

> 
> There are some similarities between JMX and Spring. The JMX spec.
> defines a MLET service, a class capable of loading JMX components
> (MBean) based on the XML-like file format.

The XML format is usually too different between different JMX Kernel implementations to get any sort of portability at all.  This is bad if you are building something you want to deploy in multiple locations (like JBoss & Websphere 5.0) because you would have to maintain a different XML file for each.

> I have always thought that Spring could play well with JMX, creating
> MBeans in the same manner as it creates "plain" beans. There are two
> things to do:
> 
> 1) Detect beans that are also mbeans and register them with the
>     MBeanServer. This should be very easy to do. Spring already
>     supports bean initialization, we have a name - there is only
>     call to mserver instance missing. Of course, there are more
>     complex things to deal with but not much.

Only if you have to do something special..  There is actually a much better way in my opinion -- see below.

> 2) Expose normal beans as JMX MBeans. This would allow any bean to
>     be manipulated through the JMX protocol. This is also easy to do
>     although there is more work involved.

Actually, I think this can be a lot less work if done right, and provide portability too.  The JMX spec requires a JMX kernel to provide a "model" mbean - the RequiredModelMBean.  The RequiredModelMBean has a no-arg constructor (RequiredModelMBean()) and also has JavaBean style setters for most pieces of the required data.  (Does Spring support passing two fields to a setter?) Also since Spring supports constructors now you should be able to "construct" a ModelMBean using only Spring.  OR, if Spring cannot currently do this directly (because it cannot pass two fields to a setter) building a generic Spring ModelMBean factory shouldn't be too tough.  Then this ModelMBean factory could be used to construct any ModelMBean you need.  

ModelMBeans are pretty cool because you can have them invoke arbitrary getters / setters / functions on your java code.  So once the Generic ModelMBean factory is built (if it even has to be) you can use it to "construct" a JMX MBean at startup using Spring, and have this MBean invoke operations on your standard javabeans.  This allows you to pretty much expose any operation or property of your beans via JMX without having to write new code.  Additional JMX MBeans or capabilities is as easy as changing your spring config.  Also, since the RequiredModelMBean is available in EVERY JMX kernel, and it's API is set by the JMX spec, you have true portability.  Not bad eh.

I haven't done this yet, but it is how I thought the problem could be approached.  Now to complete the circle all you need is to persist the modifications your JMX calls make.  Thus the suggestions I made earlier on the list about storing configuration in a database, and then having Spring reload. (see the archives)  Then instead of having the JMX ModelMBean invoke operations on the setters, you have it invoke operations on the DB via DAO.  Then reload spring and all changes take effect.  (of course your app has to be designed to support reload).  You can still "wire up" your javabeans to obtain read only performance type information.  Springs support for events in the application context would be helpful here.  (P.S. Spring needs more work in the event handling area to be more robust - threading issues are pretty much ignored in the current implementation.)

Hope this helps out.  When I get some spare time I hope to do a lot of these things with Spring - and contribute some patches too.  But that is going to have to wait a little while. :(

Later
Rob

Thread: Re: [Springframework-developer] Spring & JMX

springframework-developer