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 >>>> 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?
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="**/*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?
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.
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.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 ?
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 :)
James ------- http://radio.weblogs.com/0112098/
