The Modeler component of the Jakarta 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.0) 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).
Modeler has been tested with two different JMX implementations:
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.
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):
<?xml version="1.0"?>
<!DOCTYPE mbeans-descriptors PUBLIC
"-//Apache Software Foundation//DTD Model MBeans Configuration File"
"http://jakarta.apache.org/commons/dtds/mbeans-descriptors.dtd">
<mbeans-descriptors>
<!-- ... other MBean definitions ... -->
<mbean name="Group"
className="org.apache.catalina.mbeans.GroupMBean"
description="Group from a user database"
domain="Users"
group="Group"
type="org.apache.catalina.Group">
<attribute name="description"
description="Description of this group"
type="java.lang.String"/>
<attribute name="groupname"
description="Group name of this group"
type="java.lang.String"/>
<attribute name="roles"
description="MBean Names of roles for this group"
type="java.lang.String[]"
writeable="false"/>
<attribute name="users"
description="MBean Names of user members of this group"
type="java.lang.String[]"
writeable="false"/>
<operation name="addRole"
description="Add a new authorized role for this group"
impact="ACTION"
returnType="void">
<parameter name="role"
description="Role to be added"
type="java.lang.String"/>
</operation>
<operation name="removeRole"
description="Remove an old authorized role for this group"
impact="ACTION"
returnType="void">
<parameter name="role"
description="Role to be removed"
type="java.lang.String"/>
</operation>
<operation name="removeRoles"
description="Remove all authorized roles for this group"
impact="ACTION"
returnType="void">
</operation>
</mbean>
<!-- ... other MBean definitions ... -->
</mbeans-descriptors>
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.
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:
InputStream stream = this.getClass().getResourceAsStream
("/com/mycompany/mypackage/mbeans-descriptors.xml");
Registry.loadRegistry(stream);
stream.close();
Registry registry = Registry.getRegistry();
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.
When your server application needs to instantiate a new MBean and register
it with the corresponding MBeanServer, it can execute code like
this:
Group group = ... managed component instance ...;
MBeanServer mserver = registry.getServer();
ManagedBean managed = registry.findManagedBean("Group");
String domain = managed.getDomain();
if (domain == null) {
domain = mserver.getDefaultDomain();
}
ModelMBean mbean = managed.createMBean(group);
ObjectName oname = ... object name for this mbean ...;
mserver.registerMBean(mbean, oname);
After the Model MBean has been created and registered, it is accessible to
JMX clients through the standard JMX client APIs. A comprehensive example
that illustrates these techniques is the administrative web application that
manages a Tomcat 4.1 server, including the ability to save an updated copy of
the conf/server.xml file that represents the current configuration
of all Tomcat components.