geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dragomir Milivojevic <>
Subject Re: JMX as a kernel (was: Re: geronimo and avalon?)
Date Mon, 11 Aug 2003 11:20:29 GMT
Hi All,

I'm apparently jumping into the ongoing discussion so excuse me if I'm 
making no sense.

JBoss went down the JMX route and it works, but does it mean it is a 
right choice? Innovative choice and good idea for sure, but can it be 
made smarter? Possibly... I am wandering whether a smarter decision can 
be made rather then just using "what's there" just because it is and it 
works for someone.

Somewhere down the line someone is going to say, see we at JBoss went 
this way and others are copying our solution and Geronimo is going to 
be "yeah, me too". Developing a modular kernel isn't all that difficult 
anyway and JMX might even be an overkill. What happens when Sun changes 
JMX spec? besides... Alex has few very good points IMHO.


On Monday, August 11, 2003, at 11:55 AM, Alex Blewitt wrote:

> 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 
> approach.
> 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.
> Alex.

View raw message