[Springframework-developer] Is there a case for adding arbitrary bean metadata?

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

A friend has sent me some code for adding JMX instrumentation to beans 
in a Spring container, via BeanPostProcessor. Please see the email below 
for more details. Something like this, or extended from this, could make 
its way into Spring itself.

Now what I am thinking is that when BeanPostProcessor comes into play 
(and not just for JMX), there is sometimes a usecase for being able to 
add arbitrary metadata to a bean definition inside the context. This JMX 
implementation is relatively simplistic; it instruments and exposes 
every singleton bean in the container, and exposes only the declared 
properties, but it needs to be told in a better fashion what to expose.

Now one mechanism to handle JMX instrumenting in a more specific fashion 
is to modify the DTD to add elements specifically related to JMX, and 
BeanDefinition would just be modified in a simple fashion. I don't like 
this as it's too JMX specific.

Another mechanism would be, as the deployer, for each bean that you want 
to expose, to add into the container a partner metadata bean which holds 
information on how to expose the target bean, and the JMX preprocessor 
would in fact work off these.

However, it's arguably cleaner to just add the ability to add arbitrary 
metadata to bean definitions in the container. This metadata could be 
used in any fashion by any BeanPostProcessor implementations. This 
metadata could be parallel to the existing 'property' element,, e.g.
  <bean id="x" class="x.y.z">
    <property name="y"><value>zzzzz</value></property>
    <meta-property name="a.b.c"><value>zzzzz</value></meta-property>
  </bean>
or maybe inline with existing properties, in which case Spring would 
form a parallel metadata tree to the defined properties. ie below, there 
is metadata being defined for the property 'y':
  <bean id="x" class="x.y.z">
    <property name="y">
      <value>zzzzz</value>
      <meta-property name="a.b.c"><value>zzzzz</value></meta-property>
    </property>
  </bean>

The fourth way to get info to a JMX implementation of course is source 
level javadoc style tags, as currently being used for transactions and 
other metadata.

What does everybody think of this approach to handling JMX in the first 
place, and the various mechanisms to get metadata to the JMX instrumenter?

Regards,
Colin

Michael Zielenski wrote:

>Here's the JMX code for Spring.
> 
>What's included is a BeanPostProcessor that instruments and registers beans in a given Spring context with an MBeanServer (factory wrapper bean is also provided).  I've also included a wrapper around Sun's HTTP/HTML adaptor from the RI.  Here's one way to write everything together:
> 
><beans>
> 
> <bean id="mbeanServerFactory"
>       class="com.whatever.common.spring.jmx.MBeanServerFactoryBean"
>       singleton="true"
>       init-method="initialize"
>       destroy-method="destroy"/>
> 
> <bean id="jmxHttpAdaptor"
>       class="com.whatever.common.spring.jmx.HttpAdaptorWrapper"
>       singleton="true"
>       init-method="initialize"
>       destroy-method="destroy"
>       dependency-check="object">
>     <property name="mbeanServer"><ref bean="mbeanServerFactory"/></property>
>     <property name="port"><value>9090</value></property>
>     <property name="login"><value>admin</value></property>
>     <property name="password"><value>admin</value></property>
> </bean>
> 
> <bean id="mbeanPostProcessor"
>       class="com.whatever.common.spring.jmx.MBeanPostProcessor"
>       singleton="true"
>       dependency-check="object">
>     <property name="server"><ref bean="mbeanServerFactory"/></property>
> </bean>
> 
>  ...
> 
></beans>
>
>
>That's it.  I've been compiling against Sun's RI (1.2.1), and haven't tried anything else yet.  Let me know how you make out.  Note that right now all beans declared in the config are instrumented and registered; this is obviously not ideal, so the next step would be to figure out how to convey what to instrument to the postprocessor (i.e., extend the DTD and make this part of RootBeanDefinition?  provide in the postprocessors config? etc).
>
>-----Original Message-----
>From: Colin Sampaleanu 
>Sent: Monday, November 03, 2003 4:50 PM
>To: Michael Zielenski
>Subject: RE: Spring questions
>
>
>That's pretty cool.   From what I know, now that sun has become a bit less restrictive about bundling sun JMX classes, and have actually finished the spec for the transport (it was never specified before), some people are going back to the RI.
> 
>In any case, I wouldn't mind looking at your stuff maybe. Perhaps it can go into Spring itself.
> 
>
>-----Original Message-----
>From: Michael Zielenski 
>Sent: November 3, 2003 4:46 PM
>To: Colin Sampaleanu
>Subject: RE: Spring questions
>
>
>BTW, I added some basic JMX management to Spring, essentially a BeanPostProcessor that instruments each bean in the context, exposing its properties/attributes on the fly (no need to extend any JMX interfaces).  I used the JMX RI (1.2.1), but quickly found that trying to deploy to something like Resin was thorny since it already ships with a lame-ass JMX impl itself.  I had a look at what else is out there (MX4J, XMOJO, etc), and it seems they all bundle the javax.management classes *in their jars*...ick!
>
>-----Original Message-----
>From: Colin Sampaleanu 
>Sent: Friday, October 31, 2003 11:00 AM
>To: Michael Zielenski
>Subject: RE: Spring questions
>
>
>there's been talk of JMX support for the 1.1 timeframe
>
>-----Original Message-----
>From: Michael Zielenski 
>Sent: October 31, 2003 10:57 AM
>To: Colin Sampaleanu
>Subject: RE: Spring questions
>
>
>What about management?
>
>-----Original Message-----
>From: Colin Sampaleanu 
>Sent: Friday, October 31, 2003 10:35 AM
>To: Michael Zielenski
>Subject: RE: Spring questions
>
>
>Reconfigure is actually very hard to do due to the various lifecycles that have to be managed, postprocessing, etc. Even outright reload gets complicated, if you want to reload the same instance and have anybody holding on to it just get the new values...
> 
>
>-----Original Message-----
>From: Michael Zielenski 
>Sent: October 31, 2003 10:33 AM
>To: Colin Sampaleanu
>Subject: Spring questions
>
>
>I've seen some reload methods here and there in Spring.  How does this stuff actually work?  Is there a facility a la the log4j file watchdog that will reload the context if the underlying config changes?  That would be sweet (even sweeter if it could reconfigure existing bean instances, as opposed to recreating the context from scratch).
> 
>Also, is there any talk of adding management/instrumentation?  I guess it would be easy enough to do with the AOP stuff...
> 
>
>  
>