geronimo-dev mailing list archives

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

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

James
-------
http://radio.weblogs.com/0112098/


Mime
View raw message