Package org.apache.commons.modeler Description

The Modeler component of the Apache Commons subproject
offers convenient support for configuring and instantiating Model MBeans
(management beans), as described in the JMX Specification. It is typically
used within a server-based application that wants to expose management
features via JMX. See the
JMX Specification (Version 1.1) for more information about Model MBeans
and other JMX concepts.

Model MBeans are very powerful - and the JMX specification includes a
mechanism to use a standard JMX-provided base class to satisfy many of the
requirements, without having to create custom Model MBean implementation
classes yourself. However, one of the requirements in creating such a
Model MBean is to create the corresponding metadata information (i.e. an
implementation of the
javax.management.modelmbean.ModelMBeanInfo interface and its
corresponding subordinate interfaces). Creating this information can be
tedious and error prone. The Modeler package makes the process
much simpler, because the required information is constructed dynamically
from an easy-to-understand XML description of the metadata. Once you have
the metadata defined, and registered at runtime in the provided
Registry, Modeler also supports
convenient factory methods to instantiate new Model MBean instances for you.

The steps required to use Modeler in your server-based application are
described in detail below. You can find some simple usage code in the unit
tests that come with Modeler (in the src/test subdirectory of the
source distribution), and much more complex usage code in Tomcat 4.1 (in the
org.apache.catalina.mbeans package).

. More advanced uses can
be found in Tomcat 5 and jakarta-tomcat-connectors.

After unpacking the release, you will need to ensure that the appropriate
JAR file (jmxri.jar or mx4j.jar) is included on your
compilation classpath, and in the classpath of your server application when it
is executed.

2. Create a Modeler Configuration File

Modeler requires that you construct a configuration file that
describes the metadata ultimately need to construct the
javax.management.modelmbean.ModelMBeanInfo structure that is
required by JMX. Your XML file must conform to the
mbeans-descriptors.dtd
DTD that defines the acceptable structure.

Fundamentally, you will be constructing an <mbean>
element for each type of Model MBean that a registry will know how to create.
Nested within this element will be other elements describing the constructors,
attributes, operations, and notifications associated with this MBean. See
the comments in the DTD for detailed information about the valid attributes
and their meanings.

A simple example configuration file might include the following components
(abstracted from the real definitions found in Tomcat 4.1's use of Modeler):

This MBean represents an instance of org.apache.catalina.Group,
which is an entity representing a group of users (with a shared set of security
roles that all users in the group inherit) in a user database. This MBean
advertises support for four attributes (description, groupname, roles, and
users) that roughly correspond to JavaBean properties. By default, attributes
are assumed to have read/write access. For this particular MBean, the roles
and users attributes are read-only (writeable="false"). Finally,
this MBean supports three operations (addRole, removeRole, and
removeRoles) that roughly correspond to JavaBean methods on the underlying
component.

In general, Modeler provides a standard ModelMBean implementation
that simply passes on JMX calls on attributes and operations directly through
to the managed component that the ModelMBean is associated with. For special
case requirements, you can define a subclass of
BaseModelMBean that provides override
methods for one or more of these attributes (i.e. the property getter and/or
setter methods) and operations (i.e. direct method calls).

For this particular MBean, a custom BaseModelMBean implementation subclass
is described (org.apache.catalina.mbeans.GroupMBean) is
configured. It was necessary in this particular case because several of the
underlying Catalina component's methods deal with internal objects or arrays of
objects, rather than just the Strings and primitives that are supported by all
JMX clients. Thus, the following method on the Group interface:

public void addRole(Role role);

is represented, in the MBean, by an addRole method that takes
a String argument representing the role name of the required role. The MBean's
implementation class acts as an adapter, and looks up the required Role
object (by name) before calling the addRole method on the
underlying Group instance within the Server.

3. Create Modeler Registry at Startup Time

The metadata information, and the corresponding Model MBean factory, is
represented at runtime in an instance of Registry
whose contents are initialized from the configuration file prepared as was
described above. Typically, such a file will be included in the JAR file
containing the MBean implementation classes themselves, and loaded as follows:

Besides using the configuration file, it is possible to configure the
registry metadata by hand, using the addManagedBean() and
removeManagedBean() methods. However, most users will find
the standard support for loading a configuration file to be convenient
and sufficient.

Modeler will also look for a mbeans-descriptors.xml in the same package
with the class beeing registered and in its parent. If no metadata is found,
modeler will use a number of simple patterns, similar with the ones used by
ant, to determine a reasonable metadata

In a future version we should also support xdoclet-based generation of the
descriptors

4. Instantiate Model MBeans As Needed

When your server application needs to instantiate a new MBean and register
it with the corresponding MBeanServer, it can execute code like
this: