cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: JMX integration
Date Fri, 23 Dec 2005 10:44:19 GMT
Hash: SHA1

On Fri, 23 Dec 2005, Carsten Ziegeler wrote:

> Date: Fri, 23 Dec 2005 09:19:39 +0100
> From: Carsten Ziegeler <>
> Reply-To:
> To:
> Subject: Re: JMX integration
> Giacomo Pati wrote:
>>>>> 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.
> I can't imagine a real good solution that is *not* in the core and I
> think adding JMX support to the core makes more sense as this enables
> JMX for everything, even for block management or whatever.

Yes, this was my intention for adding JMX support (one can think of a 
block that offers JMX support/services for non ECM++ Components).

> From your description I got the impression that this is an optional
> dependency, so we need it just for compilation, right? I see absolutely
> no problem with this. If we block new great things just because they add
> a new dependency we will never get any further.

Yes. The implementaion I have now checks whether the Container (i.e. 
Servlet Engine) has launched a JMX-Agent (MBeanServer) to activate JMX 
support at all. So this is the dependency on the JMX interfaces which 
obviously will be needed at runtime as well (I probably don't know 
whethere this can be encapsulated into i.e. static helper classes to 
avoid needing the JMX interfaces at runtime at all). Anybody has 
knowledge whether this is doable without heavy introspection/reflection 
stuff to prevend needing the JMX interfaces at runtime?

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


View raw message