Menu
▾
▴
[Springframework-developer] Re: Is there a case for adding arbitrary bean metadata?
|
From: roger h. <apo...@sn...> - 2003-11-05 10:38:00
|
Hi Colin Funny you should mention this, I had a similar line of thought a couple of days ago, & also concluded that option 3, ie the use of <meta-property></meta-property> was a natural solution. However, I don't think it needs to be exclusive to option 4, ie source level javadoc style tags. The two can happily co-exist as long as the mechanism for resolving meta-data has a pluggable chain of handlers. I guess in the normal scheme of things this handler chain would look in the bean definition file, ahead of the any attributes generated from the original source code. For a good description of this sort of mechanism see the JBoss AOP docs: http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/pro jects/jboss/aop#chaining Oh the meta-joys of life ;) Roger "Colin Sampaleanu" <co...@br...> wrote in message news:3FA...@br...... > 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... > > > > > > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ |
