cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thor Heinrichs-Wolpert <>
Subject Re: [RT] On building on stone
Date Thu, 25 Mar 2004 16:45:56 GMT
Possibly, but JMX is also used to load and unload components.  If the 
API matched, I can replace any component at runtime with a simple 
config change.

JMX forms the kernel of JBOSS to handle all of it's inter-core loading 
and can act as a runtime message-plane for communicating between 

It has more to it than just the ability to see into objects or 
components through an MBean.

In the product I was referring to, we just update the config of the 
server in its datastore (JMX allows us to use flat files, XML files and 
databases if the API is consistent for the component) and then message 
the backplane to reload, change, alter, download new components in 
jars, etc. all at runtime.  The one thing we are adding in is MD5Urls 
which is a new thing in the Jini API allowing us to distinguish between 
different versions of similarly named jars.

So I think JMX can be a bolt on, or an underpinning depending on how 
you use it.  I'd be surprised if it didn't meet the core of what you 
described blocks needed.  If a block has a consistent API (Interface) 
then any block that supports that API could be loaded/unloaded and 
messaged to from other components using the JMX services and usage 

Thor HW

On 25-Mar-04, at 7:16 AM, Stefano Mazzocchi wrote:

> Thor Heinrichs-Wolpert wrote:
>> Sounds good ... as you may remember when you started to talk about 
>> Blocks in Ghent we started talking about JMX then as well.  It may 
>> not have everything you want or need, but it does have some good 
>> points and a basic lifecycle.  I believe that MX4J 
>> ( is released under an Apache license 
>> and is also being used in Geronimo.  I think it would be worth 
>> examining it as a piece of the Core needed for blocks.
>> I can say that in a previous commercial endeavour I used JMX as the 
>> core to manage all of the component loading, monitoring and 
>> distribution.
>> I'm willing to pitch in here ... and after March 29th able to as well.
> Thor,
> there is a great deal of value in having a JMX wrapper around our 
> blocks, but just to let JMX do what JMX is supposed to: remote 
> management and configuration.
> At the same time, I think JXM is not capable of doing what we need for 
> cocoon blocks, so it cannot be used as the core and, even more 
> important, it's not something we control.
> The important thing is both stability of our foundations and the 
> ability to evolve them (without passing thru a massive world-impacting 
> political JSR).
> -- 
> Stefano.

View raw message