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.
</intro>
<background>
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.
</background>
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 gpl'ed).
Does it matter if I use an ANT get task to download the lib from ibiblio.org?
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 cocoon-blocks.
Cheers all, Thor HW
