Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Thu, 25 Mar 2004 08:45:56 -0800
From: Thor Heinrichs-Wolpert <thor@lunartek.com>
Subject: Re: [RT] On building on stone
In-reply-to: <4062F7B5.6030509@apache.org>
To: dev@cocoon.apache.org
Message-id: <E2E9572C-7E7B-11D8-824F-00039388DCEE@lunartek.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <40603ACA.2070303@apache.org>
 <B5290205-7E3B-11D8-824F-00039388DCEE@lunartek.com>
 <4062F7B5.6030509@apache.org>

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 
components.

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 
guidelines.

Thoughts?
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 
>> (http://mx4j.sourceforge.net/) 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.
>