Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43A9ECA9.6090807@odoko.co.uk>
Date: Wed, 21 Dec 2005 16:00:41 -0800
From: Upayavira <uv@odoko.co.uk>
Organization: Odoko Ltd
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051011)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: JMX integration
References: <Pine.LNX.4.64.0512051701370.11170@lapgp.otego.com>
 <7557e99f0512050904p789ad916t147f2ba26ff13b2@mail.gmail.com>
 <Pine.LNX.4.64.0512152229150.8502@lapgp.otego.com>
 <43A9ECEA.9080208@apache.org>
In-Reply-To: <43A9ECEA.9080208@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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