geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Kernel Architecture
Date Tue, 12 Aug 2003 13:42:23 GMT

On Tuesday, August 12, 2003, at 02:17  pm, Alex Blewitt wrote:
> On Tuesday, Aug 12, 2003, at 12:54 Europe/London, James Strachan wrote:
>> On Tuesday, August 12, 2003, at 12:27  pm, Alex Blewitt wrote:
>>> On Tuesday, Aug 12, 2003, at 12:17 Europe/London, James Strachan 
>>> wrote:
>>>> On Tuesday, August 12, 2003, at 11:36  am, James deGraft-Johnson 
>>>> wrote:
>>>>> I like the suggestion that even if we decide to go with the MBean 
>>>>> model, a
>>>>> layer be created, possibly via an interface so this software isn't 
>>>>> tightly
>>>>> coupled to MBeans.
>>>> An interface based MBean is just a naming convention. There is no 
>>>> tying to anything. Indeed there's not even a dependency on JMX 
>>>> never mind any other container API. Then the container is totally 
>>>> free to go in whatever direction it wishes.
>>> But by creating (and calling) them MBeans, you are tying it down to 
>>> a naming convention expected by JMX which may confuse the issue 
>>> later.
>> Why? Whats confusing about it? Why would inventing yet-another-API be 
>> any less confusing?
> Becuase the MBeans are the naming convention for JMX beans. Call them 
> something else, then you don't have the dependency.
> A naming convention is as much a dependency as a code requirement.


>>> Changing things after they've been done is much more difficult than 
>>> before they've been done :-)
>> If thats your argument then its already too late to change away from 
>> MBeans. Geronimo has plenty of MBeans already - so has Tomcat, Jetty, 
>> JBoss etc. Any container should be able to easily work with these 
>> components today irrespective of tomorrows container.
> True, which is why I suggested creating an MBean container to run 
> within Geronimo.

We've already got one - its in CVS.

>>>>> Whatever we do, the ease of implementation, such as ease of kernel 
>>>>> and
>>>>> service development should be paramount. The easier it is to 
>>>>> develop, the
>>>>> greater the chances that we can focus on removing bugs and 
>>>>> increasing
>>>>> performance.
>>>> Agreed.
>>>> Which is why I think us all developing MBeans to start with is the 
>>>> easiest approach. They are very simple. Take a look at some of them 
>>>> in CVS (they end with *
>>> But creating a category of different types (Service, Component etc.) 
>>> that developers implement is even easier. Ideally, those two should 
>>> be the only two types that implement any kind of MBean interface; 
>>> and the remainder of the code developed /doesn't/ need to have the 
>>> MBean suffix.
>> I don't see the need as this appears to be unnecessary coupling. 
>> However be that as it may - it doesn't change the original premise - 
>> of writing MBeans for now until we come up with something better 
>> later on. Afterall we have lots of MBeans today we should support.
> We can introduce the new types, and write to them, and then refactor 
> existing code over. Why the fuss about MBeans? We could still support 
> existing MBeans in an MBeanContainer.

We want to support MBeans as we already have MBeans and an MBean 
container and plenty of external MBeans we wish to reuse. We want to be 
fully JSR 77 and 88 compliant.

There's no reason why you Alex can't write your own AlexContainer and 
drop it into Geronimo and support any component model you wish. Ditto 
for Avalon & PicoContainers etc.

>>> The more JMX dependencies that get added now, the more difficult it 
>>> will be to change at a later stage. So by abstracting into a common 
>>> super type(s) now, we can write to a generic API that will be easier 
>>> to migrate later, rather than having everything being MBean-based.
>> There are no dependencies. Its a very common *naming-convention* used 
>> throughout the J2EE world.  I don't see any problem using this 
>> established standard rather than yet-another-container-API.
> It isn't a common naming convention.


Look in the codebases of Geronimo, Tomcat, Jetty, JBoss, mx4j and 

> It's the JMX spec. The reason why it's used 'Throughout the J2EE 
> world' is because that's the way that JBoss does it. Many other J2EE 
> servers don't.


> And the point of this discussion, and the rest of the threads 
> regarding this (including the Wiki pages) is to think of how it could 
> be done in different ways, and propose advantages/disadvantages.

Sure lets by all means brainstorm and think of what the future 
container could be. However remember what the goal of Geronimo is - to 
create a full J2EE stack. It doesn't have to have the ultimate J2EE 
container framework inside it from day one.

The point of my original thread was to get us started writing services 
that bind into the existing JMX based container along with the existing 
MBeans in Geronimo, Tomcat, Jetty, mx4j and elsewhere while allowing 
those interested in the internals of the container to go off in their 
own direction in parallel. The writing of other J2EE services is *high* 
priority and absolute requirement. Thinking up an alternative component 
model to MBeans is quite low IMHO - its a nice to have, not a 

I don't want developers wishing to integrate the multitude of other 
parts to get J2EE compliance to sit and wait for some new component 
model which may or may not come out of some brainstorming session. If 
another component model comes along in the future we can look at using 
it. Until then I firmly believe our best course of action is to use 
MBeans as the default component model for course grained services - and 
plug anything else in using some custom adapters/containers.


View raw message