Generating MBeanFeatureInfo values for Standard MBeans

[cptnkirk]

I'm reading J & M's JMX book now (great book, comments going up on Amazon shortly). I do have a question though. Since MBean*Info classes are generated via introspection by the MBeanServer the book says that figuring out the description is impossible.

However aren't Javadoc comments used for exactly this purpose? What would be the issues in using the javadoc mechanism to populate the descriptions for these classes. Sure there would be a performance hit at deploy time, but other than that it does seem doable. And since a programmable interface to javadoc was added, I would think that this feature wouldn't even be that hard to implement.

Yea, I know what Marc is going to say. If it's so easy, why don't I do it. Well I may, I'm just asking people that are more experienced if they can see more problems in including this as a feature.

If someone were to implement this feature would the deploy time delay be acceptable to the rest of the jboss developers? Users?

[adrian.brock]

Do you know how long it takes run javadoc over a
single source? You have to create a new JVM because
javadoc does System.exit() when its finished.

JBoss would take about 5 to 10 minutes just to boot-up.

This will be going away soon. We are moving to XMBeans
in JBoss so descriptions and other MBean*Info/Descriptor
information will be provided.

Regards,
Adrian

[cptnkirk]

I haven't used it, but with JDK 1.4 there are now public methods which allow you to run javadoc programatically. These methods don't call System.exit().

I'm also not talking about the MBeans that make up JBoss. As you said, they are dynamic MBeans and wouldn't use this mechanism anyway.

What I'm talking about is for Joe user who wants to use JBossMX with his Standard MBean. When he goes to deploy his MBean his attribute definitions will have some default value. This doesn't neccesarily need to be the case. If present, Javadoc comments could be used to populate the definitions. I have no idea the performance implications, so maybe this could be a configurable optional feature on an MBean by MBean basis.

[adrian.brock]

Ok,

On [my] list of things to do is to allow customization
of the registration process using an interceptor stack
approach on the MBeanRegistry MBean.

When this is done, you might be able to add your own
javadoc/StandardMBean interceptor to do this?
This would be JBossMX specific, it wouldn't work with
other JMX implementations.

Regards,
Adrian

[cptnkirk]

I understand that this would be a JBossMX specific feature, but a value add none the less. And Joe user could use this feature without any change to his code.

Tell me more about your intercepter stack. Will this be internal, or will users be able to configure which interceptors they want to use (and in which order)? What will the scope be (per bean, per type, etc)?

-Jim

[adrian.brock]

I haven't gone through the detais yet, but the
registration process lends itself nicely to interception.

The current MBeanRegistry.registerMBean function does

1) Check the compliance of the MBean and get the
capablities
2) Perform any preRegister function
3) Determine the final ObjectName
4) Construct the Invoker
5) Register the invoker
6) If it is a classloader add it to the loader repository
7) Send MBean created notification
8) Return the object instance

Somewhere in that stack, you add could your processing
to augment the MBean*Info of a StandardMBean
(how you determine the location of the source is
left as an excercise to the reader)

The registry is per MBeanServer.
The configuration options for interceptors are still
work in progress for JBossMX.
JMX1.5 will provide a standard mechanism for
configuring interceptors. But most JMX implementations
won't expose the registry for management.

NOTE: The main idea behind the registry as an MBean
is so we can add a SecurityInterceptor to stop rogue
applications registering and unregistering MBeans.

Regards,
Adrian

[cptnkirk]

Sounds interesting. My initial reaction though is that this should be something that is more flexable rather than less. Something the user should be able to play with. Especially if they don't want something like security for their MBeans. Having this as a per registry thing now means that they have to either worry about security, or use a different registry. Now they're keeping track of multiple things where I think there should be a way to make this feature optional while keeping the overall complexity the same for the end user.

Anyway, I'm gunna get a few hours sleep. Maybe this will be clearer in the morning.

Later,
Jim

[adrian.brock]

If you want more flexibility don't use Standard MBeans :-)

Regards,
Adrian

[davidjencks]

ummmm... since when is javadoc included in compiled code??

If you are starting with the sources, I have already done this. Use xdoclet and the jboss-xmbean subtask. It will use the xdoclet markup to generate an xml xmbean descriptor that among other things uses the javadoc descriptions as the descriptions. You get to use model mbean rather than standard mbean, but this also saves you from that extra interface.

I'm waiting for the new stuff from trevor to make sure it works, very little required functionality is implemented in the interceptors in cvs.

[juha]

just to add more confusion to the topic, I'll add my own bits :)

> What I'm talking about is for Joe user who wants to
> use JBossMX with his Standard MBean. When he goes to
> deploy his MBean his attribute definitions will have
> some default value. This doesn't neccesarily need to
> be the case. If present, Javadoc comments could be
> used to populate the definitions. I have no idea the
> performance implications, so maybe this could be a
> configurable optional feature on an MBean by MBean
> basis.

Adrian is right in that if you want to start adding new information to your management interfaces your best bet is to migrate to Model MBeans. Today you may only want to add descriptions but I can guarantee that by tomorrow you'll go... 'hmm, I want this class Foo to be my attribute type but the HTTP adaptor doesn't know how to present it, even though the constructor only requires two strings and an int'. Or something similar. :)

So you'll end up building big hacks around the Standard MBean mechanism.

If you already have alot of Standard MBeans built and are just looking for an easy way to get them converted as Model MBeans, then the XMBean implementation is currently able to build an exact copy of your Standard MBeans and present it as an Model MBean template. What you would need to change is the way you register your MBean. So for instance if you have code like this:

server.registerMBean(new MyStandardMBean(), new ObjectName(":foo=bar"));

You would need to replace it with:

server.registerMBean(new XMBean(new MyStandardMBean(), "StandardInterface"), new ObjectName(":foo=bar"));

This would tell the XMBean implementation that the object reference you pass to it is actually a standard MBean implementation and the XMBean uses the same code as the server to build the MBeanInfo description of your MBean (with some additional default descriptors).

Now this alone won't yet give the descriptions to you. But now you are in control of how the metadata for your MBean is being built (instead of relying the black box of an agent to do it for you). The XMBean allows you to plug in different MetaDataBuilder implementations that it uses to create the MBeanInfo structure, and picks one based on the resource type string you supply when you create the ModelMBean. You could take the existing StandardMetaData class and extend it to recognize an additional method from your interface, say getAttributeXXXDescription() that is called to retrieve the description. Or you can implement the javadoc idea and pick the description up from the source (you need to config the ModelMBean with additional info where to find the source file).

Then modify the XMBean to recognize a new resource type string "MySuperDuperInterface" that picks your implementation of metadata builder and adds that description to your MBeanInfo (or any other thing you wish it would do). You could even throw away the whole standard naming scheme and invent your own if you really really want to.

So there is one more idea to ponder about.

-- Juha

[cptnkirk]

> ummmm... since when is javadoc included in compiled code??

Hmmm, when indeed. Answer, not yet as far as I know. It's strange, I know that comments aren't kept in compiled code. I've even written a Java compiler in the past. But for some reason last night it was if Java all of a sudden supported this feature (like it had always supported it).

You got me, the problem is not quite as trivial as I once thought. And it may be (probably is, definitely is) impossible to do given compiled code alone and Java's current feature set. Although I suppose this could change in the future (when object size no longer matters and people really need this level of introspection support).

Anyway, it sounded like a good idea at the time. I suppose I could add a feature that uses the src of a SMBean to generate the descriptions, but this wasn't my original intent. Sounds to me like I need to learn more about XMBeans. They sound pretty nice and sound like they provide some of the dynamic/extensible features I was hoping to hack into SMBeans.

Thanks all for your comments.

[cptnkirk]

You know I guess what I was feeling when I came up with this idea was the need for declarative middleware in JMX. The JMX platform is so close to J2EE in the way it abstracts and proxies information to registered MBeans (similar to EJBs), that it would seem only logical to support middleware services in the same way.

JMX already provides for a suite of standard services (persistance, attribute caching, timing, monitoring, notification). You want to add security. I think what I was trying to do would be to add another related service.

Model MBeans support a lot of these features already via descriptors, but their usage is still hard coded with tight coupling to the MBean Agent. If only there were a concept of a deployment descriptor and a MBAR (MBean Archive) that the JMX container could use to provide these services in a more pluggable fashion.

Now I'm still rather new to JMX so maybe this is in the works. And hey, if you tell me that's what XMBeans are I'm totally stoked. I've got more reading to do. What is the community's thought on this?

-Jim

[cptnkirk]

Instead of building more J2EE support into JMX, maybe it would be better to build more JMX into J2EE. I'm sure others have already come to this conclusion as well. Anyone know how far their work has come, or where I could read more about it?

[juha]

> Instead of building more J2EE support into JMX, maybe
> it would be better to build more JMX into J2EE. I'm
> sure others have already come to this conclusion as
> well. Anyone know how far their work has come, or
> where I could read more about it?

I don't know if there is anywhere you can read about it yet, the latest "hear-say" I have from this week is that JMX integration with J2EE is "done", there are investigations on including it as part of J2SE and people are experimenting with J2ME.

J2EE could mean version 1.4, though I'm not absolutely certain (there were some security issues that needed to be fixed first, that ought to come out with the 1.1 maintenance release due any day now). You could try if you can find a confirmation for this in the JCP.

-- Juha

[juha]

> Model MBeans support a lot of these features already
> via descriptors, but their usage is still hard coded
> with tight coupling to the MBean Agent. If only
> there were a concept of a deployment descriptor and a
> MBAR (MBean Archive) that the JMX container could use
> to provide these services in a more pluggable
> fashion.

JBoss 3.0 supports a SAR format (Service Archive) that includes MBeans. I'm not the expert on deployment services but I think some creative stealing from that side to the JBossMX is in order at some point ;)

Right now I think they're going through some refinement, in how to handle the XML descriptors which are cumbersome to edit when packaged inside the archive with everything else. I've experimented with an MLet MBean replacement that performs the same functionality as an MLet service but allows richer description (than the MLET tag) of an application, including application component relationships and "symbolic link" resolution and other deployment related information. So an MBean loading mechanism that can bring home a set of components that compose an application or several applications. So that would be the deployment descriptor.

We'll see... very much in the experimental stage at the moment.