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. Upayavira
