-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 23 Dec 2005, Carsten Ziegeler wrote:
Date: Fri, 23 Dec 2005 09:19:39 +0100
From: Carsten Ziegeler <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
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 - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDq9UELNdJvZjjVZARAmxgAJ4uXrYk6wb2+P9DhsO2RoayRxGovQCfVn29
sQ69x1/YB+AEj+1dlnHxDco=
=LGHx
-----END PGP SIGNATURE-----
