geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: generating MBean metadata (was Re: Dynamic MBeans. Was: Kernel Architecture)
Date Wed, 13 Aug 2003 14:36:36 GMT

On Wednesday, August 13, 2003, at 03:19  pm, David Jencks wrote:
> On Wednesday, August 13, 2003, at 08:06 AM, James Strachan wrote:
>> On Wednesday, August 13, 2003, at 05:15  am, David Jencks wrote:
>>> On Tuesday, August 12, 2003, at 03:13 PM, Bordet, Simone wrote:
>>>> Hi,
>>>>> Using model mbeans instead of standard mbeans has many
>>>>> advantages.
>>>> Uhm, I admit to have little knowledge of JBoss' XMBean, but what 
>>>> are the real advantages of using ModelMBeans (and all the stuff 
>>>> they carry) ?
>>> -- you can deploy a pojo as an mbean with __no__ modification or 
>>> interface required.  For instance, in JBoss 4, the jca adapter 
>>> objects are deployed directly as xmbeans.  Thus you can see and 
>>> modify all the properties of a deployed ManagedConnectionFactory 
>>> instance.
>>> --"artificial" attributes that are not actually in the underlying 
>>> object.
>>> --attributes whose accessors don't follow the standard mbean naming 
>>> convention
>>> --you can include lots of descriptive info to display in a 
>>> management console.  This makes the console self documenting.
>>> --with an interceptor based model mbean implementation, you can add 
>>> interceptors that implement additional operations.  For instance, in 
>>> the JBoss 4 jca 1.5 support, ActivationSpec instances are deployed 
>>> directly as xmbeans.  There is an no-arg "start" operation 
>>> implemented by an interceptor that is called by the JBoss lifecycle 
>>> management and in turn calls the jca start(ResourceAdapter) method.  
>>> (the ObjectName of the deployed resourceadapter instance is held in 
>>> an "artificial" attribute).
>> Agreed. This is good. I like the idea of supporting POJOs and beans. 
>> The nice thing from Geronimo's perspective is they can be easily 
>> converted to MBeans and it doesn't need to worry about the different 
>> ways you can use to make an MBean.
>>>> I think it can be useful to have DescriptorAccessible MBean*Info, 
>>>> but once again, how do you configure it ?
>>>>> As I recall someone (Simone?) offered to write an xmbean model 
>>>>> mbean for
>>>>> mx4j.
>>>> Yes, it was me :)
>>>> I even started, but stopped after a while failing to see a definite 
>>>> use case for them. I don't say they don't have a useful use case, 
>>>> but that I fail to see it. Lack of experience on my part, I >>>>
>>>> ModelMBeans are a pain to configure (very verbose xml files) while 
>>>> most of the times the metadata can be obtained from the resource 
>>>> (at the end, you want to call its methods: why not generating the 
>>>> metadata automatically - a la std mbeans - and add only useful 
>>>> stuff ?).
>>> How can you generate the metadata without at least minimal source 
>>> code markup?  What is the useful stuff you are thinking of?
>> Incidentally, I've often found making MBeans via XDoclet painful. 
>> Typically when I have some service, I want all its public methods and 
>> attributes to be visible to JMX unless I explicitly say not to. 
>> Typically the methods I put on the service are for JMX anywyas.  So I 
>> don't wanna have to litter my code with @jmx:attribute and 
>> @jmx:operation and so forth all over the code - I find it easier to 
>> use the * interface approach.
> You find writing a * class yourself easier than including 
> the xdoclet tags?

Yes! :) Maybe its just me, but I can take advantage of refactoring 
tools etc. So I can add a method to the interface & the IDE will 
generate a method body, or use 'extract to interface' and so forth. Its 
so hard to miss a doclet tag to mess things up - hacking doclet tags 
feels like lots of extra error-prone typing - maybe I'm just lazy.

>> So I can imagine a way of generating MBeans metadata in a simple way 
>> with most of the metadata defaulted unless overridden by metadata 
>> (doclet tags or XML etc). e.g. use the normal javadoc descriptions of 
>> the service & attributes & methods unless I explicitly override it - 
>> plus default to use all public methods for introspection.
>>  e.g. this bean should be usable to generate pretty much all of the 
>> JMX metadata.
>> /** An egg timer... */
>> public class EggTimer implements Serializable {
>> 	/** Starts the egg timer */
>> 	public void start() {...}
>> 	pubic int getFoo() {...}
>> 	/** sets the foo thingy */
>> 	public void setFoo() {...}
>> 	/** @jmx:hide */
>> 	public void hack();
>> 	// the above method will be hidden from JMX
>> 	// which is the exception
>> }
>> Then in your build system you could have something like this
>> 	<xdoclet:makeJmx>
>> 		<fileset dir="src/java" includes="**/*"/>
>> 	</xdoclet:makeJmx>
> This would be a pretty easy xdoclet template to write, although 
> xdoclet might need some help to distinguish between operations and 
> attributes.  I guess we could use the javadoc for the jmx comment?

Absolutely - both on the class, methods & properties. Of course it can 
be overloaded - I'm just discussing a defaulting mechanism if you don't 
happen to specify any jmx-related doclet tags.

>  I'm not sure how to choose between the getter and setter javadoc for 
> an attribute.

Agreed. I've been meaning to have a go at trying this out for some 
time. I've discussed this with Aslak of XDoclet a few times - now he 
lives a mile away there's no excuse for not sorting it out. AFAIK 
Xdoclet2 should allow this fairly easily I hope. I basically want a 
pipeline approach.

extract doclet tags -> transformer -> xdoclet template.

e.g. take all the doclet tags & then process them with rules - adding 
sensible defaults for a project (like for all classes of a certain 
kind, name pattern, interface or package, apply some doclet tag 
defaulting rules first before generating the code). Should be easy to 
do for all kinds of XDoclet generations.

>>>>> For now we can generate standard mbean interfaces and, when we get 
>>>>> an
>>>>> xmbean impl.  switch over with minimal  effort.  Including
>>>>> appropriate documentation now will make the switch easier.
>>>> This brings me to another question: how difficult is to move to a 
>>>> plain java object (a la Avalon) and have an XMBean that can wrap 
>>>> java objects automagically ?
>>> How would it decide which operations/attributes should be exposed?  
>>> For the jca stuff I mentioned, the needed metadata is specified in 
>>> the ra.xml file.
>> Default to all of them that are available via introspection unless 
>> any metadata says not to (or hides certain things). Whether this is 
>> via XML config file or doclet tags is optional.
> This seems quite reasonable.

Phew :)


View raw message