cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: JMX integration
Date Thu, 22 Dec 2005 00:01:46 GMT
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 :)


Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Mime
View raw message