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.
-d-
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" <[EMAIL PROTECTED]>
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.
