cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thor Heinrichs-Wolpert <>
Subject jmx libs and wrappers
Date Mon, 13 Oct 2003 19:02:16 GMT
JMX is a standardized framework to uniformly instrument disparate 
chunks of Java code in a JVM.  JMX can be used to load, start, manage, 
monitor and stop software components in a standardized way.  There are 
more and more J2EE containers that continue to adopt JMX as the default 
instrumentation layer.  Several systems use the JMX environment to 
communicate between components and by doing so can load and unload 
components at runtime where the Bean interface is the same, but the 
implementations differ.

For basic JMX functionality the interfaces are well described and are 
therefore somewhat portable across implementations.

What is not well described nor portable are the JMX Connectors.  There 
is an emerging RI for remote management, but it is not released and 
therefore does not meet with standard for cocoon to only use production 
released components.  Implementing any JMX infrastructure now will 
require some customized code to utilize the specific connectors 
provided to access its JMX implementation.  The impacts can be 
mitigated by implementing a layer that mimics the JMX Remote API, which 
is looking as if it is somewhat stable.

What are the restrictions for the libs we can use within cocoon?

Can I use Sun libs, or Sun RI libs for basic jmx functionality?  JMX 
libs are also available from IBM and jboss (although the jboss ones are 

Does it matter if I use an ANT get task to download the lib from

My first pass will probably be an XML descriptor that can be used to 
describe the properties that the MBean (Managed Bean) should expose.  I 
wont add in any of the auto-loading, distribution or module 
collaboration via a jmx back-plane until I see more of the 

Cheers all,
Thor HW

View raw message