geronimo-dev mailing list archives

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

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

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 

/** 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

		<fileset dir="src/java" includes="**/*"/>

>>> 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.


View raw message