You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by James Strachan <ja...@yahoo.co.uk> on 2003/08/13 14:06:29 UTC
generating MBean metadata (was Re: Dynamic MBeans. Was: Kernel Architecture)
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.
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>
>>> 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.
James
-------
http://radio.weblogs.com/0112098/
Re: generating MBean metadata (was Re: Dynamic MBeans. Was: Kernel Architecture)
Posted by James Strachan <ja...@yahoo.co.uk>.
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.
>>>>> 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 :)
James
-------
http://radio.weblogs.com/0112098/
Re: generating MBean metadata (was Re: Dynamic MBeans. Was: Kernel Architecture)
Posted by David Jencks <da...@snappydsl.net>.
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/
>