You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Thor Heinrichs-Wolpert <th...@lunartek.com> on 2003/10/13 21:02:16 UTC

jmx libs and wrappers

<intro>
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


Re: jmx libs and wrappers

Posted by Thor Heinrichs-Wolpert <th...@lunartek.com>.
oh, and one library I really like is MX4J which I've just realized is 
distributed under an Apache license.  So unless anyone objects I'll use 
the MX4J as the core JMX services.

Now should it be an ANT get from sourceforge, ibiblio or just a local 
lib?

Cheers,
Thor HW

On Monday, October 13, 2003, at 12:02  PM, Thor Heinrichs-Wolpert wrote:

> <intro>
> 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
>
>