geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <davidjen...@snappydsl.net>
Subject Re: generating MBean metadata (was Re: Dynamic MBeans. Was: Kernel Architecture)
Date Wed, 13 Aug 2003 14:19:16 GMT

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 imagine.
>>> 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 *MBean.java interface approach.

You find writing a *MBean.java class yourself easier than including the 
xdoclet tags?
>
> 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="**/*Service.java"/>
> 	</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?  I'm not sure how 
to choose between the getter and setter javadoc for an attribute.
>
>
>
>>>> 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.

david jencks
>
> James
> -------
> http://radio.weblogs.com/0112098/
>


Mime
View raw message