geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Central piece: to JMX or not to JMX - Avalon
Date Thu, 07 Aug 2003 14:59:29 GMT

Once the code is online, take a look at the interceptor stack and see 
what you think.

On Thursday, August 7, 2003, at 03:29  pm, Alex Blewitt wrote:

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


View raw message