geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: Central piece: to JMX or not to JMX - Avalon
Date Thu, 07 Aug 2003 14:29:53 GMT
>> A: To be certified Geronimo needs to fully support JMX and JNDI. So 
>> the current plan is to follow the direction of Tomcat 5, Jetty & 
>> JBoss and to use MBeans to register & wire the services together 
>> along with JNDI.
>> Has this decision already been taken to base it entirely on JMX ala 
>> JBoss?
> So far yes. Right now like Tomcat 5, Jetty & JBoss we're using the JMX 
> component model for the foreseeable future along with our own 
> lifecycle mechanism closely tied with the J2EE deployment & 
> classloader mechanisms. Just because another services framework exists 
> it doesn't mean we have to use it. Though things may change in the 
> future.

> Remember our aim is to build a kick ass J2EE container - not reuse 
> every bit of code we can find.
>>  I really don't think that's the right way forward.
> Thats a convincing argument :) Why? I wonder why Tomcat 5, JBoss & 
> Jetty haven't jumped on Avalon either. Until we get going over here 
> why not start there first then come back here later when we're a 
> little more up to speed & things are documented & described a little 
> better & you've managed to convince Tomcat, Jetty or JBoss to ditch 
> JMX and use Avalon instead?

I ought to be clearer in my posts ;-) I didn't necessarily advocate 
Avalon over Xxx; that was in response to a previous post.

What I was saying, and had made a post to before, was that I can't see 
why we should be basing it on JMX [just because that's how Tomcat 5, 
Jetty, JBoss uses]. My opinion was that a kick-ass J2EE container would 
probably not be built on JMX, but instead provide an interface for JMX 
access on top (instead of underneath).

My reasoning behind the JMX issue is that it forces the development 
down one particular path, with a lot of JMX-intermediary-layer messages 
being bounced between different components. Removing that layer, and 
having direct messaging instead is bound to be faster, though this is a 
subjective observation rather than having detailed analysis to back 
that up. I'll do some tests and report back.

Although having a JMX interface is needed, it doesn't need to be based 
on JMX, in much the same way that in order to interoperate with CORBA 
it doesn't need to be built on top of CORBA.

These were the thoughts behind the original post, and the follow on 
from the Avalon post led me to the FAQ answer with the 'We are using 
JMX' answer, hence this query.


View raw message