-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 21 Dec 2005, Upayavira wrote:
Date: Wed, 21 Dec 2005 16:00:41 -0800
From: Upayavira <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: JMX integration
Carsten Ziegeler wrote:
Giacomo Pati wrote:
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).
Awesome. Sounds great. One of my goals for 2.2 was to add JMX support to
Cocoon, but I never really got time for it.
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?
Hmm actually I don't care that much if we add another dependency. I
rewrote the core of Cocoon and added ECM++ for being able to add JMX
support somehow. Now, it thing depending on commons-modeler is a little
bit "easier" as it's an Apache project - if there is something wrong for
us we can fix it more easily. But apart from that, I think I just trust
your decision which of the two is better suited for us.
So, big +1 for adding JMX support to 2.2 :)
So long as the new dependency isn't one for the core, but can be
contained in a block.
No, this is why I'm seeking for suggestions. JMX support has to be
implemented in the core (CoreComponentManager IIRC) and thus will
introduce new dependencies.
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)
iD8DBQFDqt/ELNdJvZjjVZARAskTAKCLBk8/zBohd/3dPYnOPorS93R7cQCfZvbM
3PjDM8pUiPdfhMFHzFYdVu8=
=c8+W
-----END PGP SIGNATURE-----
