Working with a class hierarchy of managed objects

[fizbin]

I'm certain that this must be a standard pattern, but my googling
through the JMX blogs and searching the JMX-FORUM archives were unable
to find it.

Basically, I'm looking for information about what the accepted best
practices are for the following situation:

I have several objects that all descend from one class
(AbstractWorker).  Now, this common ancestor class gives some common
operations/attributes to all its descendants which I would like to
have exposed via JMX, but some of the descendant classes also have
additional operations specific to that class which should be exposed
as well.  A minor wrinkle is that most (but not all) of the classes
that descend from AbstractWorker will be instantiated once per
application.

Here's the solution I'm using for this situation now: AbstractWorker
has a method, startUp, that is called near application startup time
(before then, it's not meaningful to manage the AbstractWorker
objects).  As the last part of this method, it does this:

  MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
  ObjectName beanName = getObjectName();
  DynamicMBean dynaBean = getDynamicMBean();
  mbs.registerMBean(dynaBean, beanName);

The default implementation of those two get* methods are (exception
handling omitted for clarity):

  protected ObjectName getObjectName() {
    return new ObjectName("com.mycompany.myproduct", "type",
getComponentName());
  }
  protected DynamicMBean getDynamicMBean() {
    return new StandardMBean(this,AbstractWorkerMBean.class);
  }

The getComponentName() method pulls out the last component of
getClass().getName(), and AbstractWorkerMBean is what you think it is
- namely, an interface that defines the JMX-exposed operations and
properties common to all AbstractWorker descendants.

Now, this lets AbstractWorkerMBean define the basic management
interface, and it lets subclasses override that with *MBean interfaces
that will extend AbstractWorkerMBean.  However, for subclasses that
don't define their own management interface, they just work.

Now the bad part - here's the problems that I know about with this design:

- I have other things in my application that are not
AbstractWorkerMBean implementors that are also registered in the
com.mycompany.myproduct namespace.  This means that it isn't easy to
do a search and get just the AbstractWorker objects.  Would it be
better to make them all the same type and distinguish based on name or
to put them all in a com.mycompany.myproduct.worker namespace?  (Or
should I do something else, like add a
"implements=AbstractWorkerMBean" attribute to the name?)  At this
point, I'm worried mostly about making things easily manageable with
third-party JMX clients - writing our own mangement interface is not
even being considered yet.

- It would probably be useful to be able to get a status listing of
all AbstractWorker subclasses, (say, packaged into a TabularData of
some type) but I don't have a convenient place to stick such a
management method.

Another problem is that I'm new to JMX in general, and so don't trust
myself to have a good design sense with it yet.

So - what have I missed in my design by being new to JMX?  How should
I structure my ObjectNames to make it easy to find all AbstractWorker
objects?

===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM".  For general help, send email to
listserv@... and include in the body of the message "help".