On Wed, 20 Feb 2002, Christopher K. St. John wrote:
> Date: Wed, 20 Feb 2002 13:05:34 -0600
> From: Christopher K. St. John <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: o.a.c.mbeans.*
>
>
> It looks like the current mbeans code is mostly boilerplate.
In what respect? If you uncomment the two listeners at the beginning of
server.xml, and set the debugging level up a few notches, you'll see that
MBeans get created for essentially all of the internal Catalina
components. The admin webapp relies on these, because it uses JMX to
manage these components.
> Is there a technical problem with using the information from
> mbeans-descriptors.xml to create dynamic mbeans that don't
> require hand-coded mbeans wrappers?
>
JMX offers three kinds of MBeans, and we chose to use ModelMBeans for
Tomcat components because they have the most built in flexibility and
functionality. However, creating the metadata that corresponds to a
ModelMBean is not for the faint of heart (check out the JMX Javadocs and
spec for all the gory details), so I created the "modeler" component to do
all the grunt work for you. The RequiredModelMBean base class that
modeler provides is based on the following design principles:
* Only expose the attributes and operations defined in the
descriptor file to JMX clients.
* By default, pass through all attribute and operation calls
to the corresponding methods of the underlying managed objects.
* Allow the MBean developer to override these calls (decorator pattern)
if necessary, on a method-by-method basis.
If you don't specify a "className" attribute on the <mbean> elements, you
will in fact get a generic ModelMBean that simply passes everything
through. However, that is not always sufficient.
In no cases did we want to modify the underlying components themselves
just to introduce management. But, an important issue is that you don't
really want to pass back references to "real" components to the JMX client
-- because it could be running in a different JVM, and those references
wouldn't be valid.
Consider the following method on the o.a.c.UserDatabase interface:
public Iterator getUsers();
Inside Catalina, this works fine -- you get an Iterator of the User
objects associated with this user database. However, that won't work for
a remote JMX client (you can't guarantee that the underlying objects are
serializable, etc.). So, the MBean version of this call returns a String
array of the object names for the user MBeans.
Even if you have a special MBean class, you don't have to re-implement
everything -- just do the methods you care about, like any other subclass
situation. But it's sure nice to be able to do things like this.
>
> --
> Christopher St. John [EMAIL PROTECTED]
> DistribuTopia http://www.distributopia.com
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
