cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: JMX integration (was: Re: [RT][long] Cocoon 3.0: the necessary mutation)
Date Tue, 06 Dec 2005 06:16:04 GMT
Hash: SHA1

On Mon, 5 Dec 2005, Gianugo Rabellino wrote:

> Date: Mon, 5 Dec 2005 23:24:22 +0100
> From: Gianugo Rabellino <>
> Reply-To:
> To:
> Subject: Re: JMX integration (was: Re: [RT][long] Cocoon 3.0: the necessary
>     mutation)
> On 12/5/05, Giacomo Pati <> wrote:
>>> On 12/5/05, Giacomo Pati <> wrote:
>>>> While we are at it. I actually have the need for some JMX
>>>> instrumentation in Cocoon 2.1. But instead of just writing some MBean
>>>> wrappers for my components, I'd like to spent some more time on it for a
>>>> more general solution to it (monitoring component pool sizes come to my
>>>> mind quickly).
>>>> Is there any interest do discuss this topic for a possible
>>>> implementation?
>>> Most definitely yes. However, be warned that retrofitting JMX to the
>>> current Cocoon architecture seemed like a big headache to me. Maybe
>>> going through Excalibur instrumentation (which I've never been able to
>>> see working) could do, otherwise expect pain. Lots of.
>> Could you elaborate a bit more? I'm interested about oppiions.
> If my memory serves me correctly (and don't count on it!) I remember
> skimming through a JMX book with growing pain and anger: basically
> what I recall is that it's trivially easy to write from scratch code
> "the JMX way", but when it comes to retrofitting (no more vanilla
> MBeans, you basically have to resort to Model MBeans) I seem to recall
> a long and outstanding pain in terms of required code to be written in
> terms of descriptos, not to mention a long sleeve of what seemed to me
> reflection based bug-prone hacks. But don't trust my FUD: go and read
> it yourself, I just gave it a cursory look at it, which left me with a
> sore feeling.

Ah,I thought you meant some Cocoon code. Actually there are tons of 
helping systems around: Apache Commons Modeler, MX4J, and even Jetty 
have some tools or base classes to inherit from to easily write Model 
MBeans (of which you are right might be the most best model).

There are tools that generate/instantiate MBeans by use of 
introspection. My experience with those is that mostly they expose to 
much functionallity to the management console.

For JMX support integration into Cocoon I'd see the ComponentManager 
(ServiceManager) as a point where JMX registration could take place. But 
I wonder how people see this happening. Patterns I've found so for in 
the JMX world are:

1. By Name Pattern:
         If there is a component called MyFooImpl, look if there is a
         class called MyFooImplMBean and registrate that one to the

2. By Interface:
         If the component is an MBean (implements one of the MBean
         interfaces) register it.

3. By a configuration attribute:
 	If the component has an attribute 'managedBy="FQCN"' instantiate
 	that FQCN and register it.

My favorites a 1. and 3.


- -- 
Giacomo Pati
Otego AG, Switzerland -
Orixo, the XML business alliance -
Version: GnuPG v1.4.2 (GNU/Linux)


View raw message