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.




Reply via email to