-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 5 Dec 2005, Gianugo Rabellino wrote:
Date: Mon, 5 Dec 2005 18:04:49 +0100
From: Gianugo Rabellino <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: JMX integration (was: Re: [RT][long] Cocoon 3.0: the necessary
mutation)
On 12/5/05, Giacomo Pati <[EMAIL PROTECTED]> 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 javax.management
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
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDoeHzLNdJvZjjVZARAiPxAJkBPtJt0cIOFeXMMleQo0DpkTsOkgCgsjNK
PgXvq1XvjidPc+nuHI46zfc=
=jdpk
-----END PGP SIGNATURE-----
