geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: JMX as a kernel (was: Re: geronimo and avalon?)
Date Mon, 11 Aug 2003 10:55:05 GMT
On Monday, Aug 11, 2003, at 07:07 Europe/London, Weston M. Price wrote:

> I agree with Gareth,I am not quite sure of why JMX would not be used, 
> or would
> be replaced at some other time.
> On Monday 11 August 2003 09:28 am, Gareth Bryan wrote:
>>> On Mon, 11 Aug 2003 04:40:40 -0400, "Noel J. Bergman" 
>>> <>
>>> said:
>>> Jason Dillon wrote:
>>>> we will eventually want to replace the JMX bus with a more
>>>> robust component system.
>>> The sense I am getting from the list is that there is a decent sized 
>>> base
>>> of
>>> people who agree with you, and who see JMX as an interface TO a 
>>> component
>>> system, not AS the component system.
>> I get that sense aswell, although personally, I haven't spoken up 
>> about
>> it before now because I wanted to take a look at the seed code. My
>> initial opinion is that I'd like to see some hard evidence for the
>> drawbacks for using JMX, putting it another way: I'm a +1 for JMX at 
>> the
>> moment.

A number of people are saying 'Lets go with the JMX bus until another 
choice is made later'. The question is, why was the JMX bus chosen in 
the first place? Because other implementations (e.g. JBoss) used that 

The problem is that JMX was designed as an interface to allow remote 
programs to manage/start/stop services on a remote machine using an 
arbitrary client. JBoss does as much in its administration console, 
which is nothing more than a glorified send-a-JMX-message system.

The other reason why JMX is used as the initial bus is that J2EE must 
have a JMX interface. That said, it doesn't need to be implemented 
using JMX (in much the same way that we don't need to build a J2EE 
server using CORBA although CORBA requests may/must be supported).

Unfortunately, the isA/hasA debate is something that can run and run 
and run, and since the initial code seed has gone with JMX then it 
seems very difficult to nudge that another way. But a more generic 
container framework (the likes of 
Avalon/Merlin/Hivemind/Eclipse-Plugin-Style) that /has/ a JMX interface 
would be a 'cleaner' approach from an OO perspective.

There is also a potential danger that if JMX is used as the bus for the 
kernel, then developers will think it's a good idea to use JMX for all 
the intra-kernel messages. JMX was designed to be a /Management/ 
interface, not a system for passing messages between components.

Lastly, if the focus is on 'The kernel is JMX' then that may 
unnecessarily affect design decisions: 'Hey, lets use MBeans defined in 
XML on a single flat file'. We could follow JBoss' example and do this; 
or we could be more innovative, using a configuration registry backed 
with JNDI/LDAP, whilst still providing a Management interface over JMX.


View raw message