cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: JMX integration
Date Thu, 22 Dec 2005 17:17:55 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 21 Dec 2005, Upayavira wrote:

> Date: Wed, 21 Dec 2005 16:00:41 -0800
> From: Upayavira <uv@odoko.co.uk>
> 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-----

Mime
View raw message