cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: JMX integration (was: Re: [RT][long] Cocoon 3.0: the necessary mutation)
Date Thu, 15 Dec 2005 21:36:51 GMT
Hash: SHA1

On Mon, 5 Dec 2005, Gianugo Rabellino wrote:

> Date: Mon, 5 Dec 2005 18:04:49 +0100
> From: Gianugo Rabellino <>
> Reply-To:
> To:
> Subject: Re: JMX integration (was: Re: [RT][long] Cocoon 3.0: the necessary
>     mutation)
> On 12/5/05, Giacomo Pati <> wrote:
>> While we are at it. I actually have the need for some JMX
>> instrumentation in Cocoon 2.1. But instead of just writing some MBean
>> wrappers for my components, I'd like to spent some more time on it for a
>> more general solution to it (monitoring component pool sizes come to my
>> mind quickly).
>> Is there any interest do discuss this topic for a possible
>> implementation?
> Most definitely yes. However, be warned that retrofitting JMX to the
> current Cocoon architecture seemed like a big headache to me. Maybe
> going through Excalibur instrumentation (which I've never been able to
> see working) could do, otherwise expect pain. Lots of.

I now do have a working implementation for JMX with the least impact (by 
added dependencies) to the core (so far only the 
interfaces). The discovery approach is simply looking whether there is a 
class which has the MBean suffix to the FQCN of the Component target for 
Management. This means you'll have to write your MBeans by hand (yes 
there are helper base classes available somewhere else and I will write 
about this below). The code I've written checks whether there is a 
MBeanServer available in the JVM and only adds JMX discovery support if 
there is one (doesn't create an MBeanServer on it's own so far like 
Commons-Modeler does).

I was also asking myself (and now you guys) whether we should depend on 
Commons-Modeler which has some nice conveniences to add JMX ModelMBean 
support by xml configuration files and/or subclassing of their 
BaseModelMBean helper class.

Other helper base classes I've found is the 
org.mortbay.util.jmx.ModelMBeanImpl which make writing MBean classes 
very easy (I think there is also some generating introstecting method 
like Commons-Modeler does) and also supports array of managed objects 
which would come handy for pools of manageable components (which 
Commons-Modeler base classes doesn't seem to support, only primitive 
data types). The ModelMBeanImpl base class supports resource properties 
file which respect the locale of the machine the JVM runs on for the 
descriptions of the mbean attributes/operations etc. which should be 
shown in the JMX-Console.

A word to "components targeted for Management":

In 2.1 the support for JMX is quite limitted as we do not control the 
code of the Component Management parts (it's Excalibur code and I 
wouldn't take the effort to change it) and thus targets are only 
components which a ThreadSafe and implement the Component interface 
(maybe more components could be a traget for management but so far I've 
only choosen those).

In 2.2 the situation is much more comfortable (as we control the 
component management code). There I'll have support ready for any 
ThreadSafe components as well as for the 
NonThreadSafePoolableComponentHandler (for the min/max values of the 
pools by use of the ModelMBeanImpl base class but this can be changed to 
Commons-Modeler). Adding management for pools of components will depend 
on which JMX supporting package we decide to choose. With 
Commons-Modeler I think it would be a more code to write thanwith the 
mortbay ModelMBeanImpl base class.

The question I'd like to discuss is whether we wan't add a supporting 
package (Commons-Modeler or jetty/mortbay's ModelMBeanImpl) or should we 
just stay with the support to add MBeans (how ever those are implemented 
is up to the user) to a possibly running MBeanServer in the JVM?

Thanks and Ciao


- -- 
Giacomo Pati
Otego AG, Switzerland -
Orixo, the XML business alliance -
Version: GnuPG v1.4.2 (GNU/Linux)


View raw message