geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: Kernel Architecture
Date Tue, 12 Aug 2003 13:59:13 GMT

On Tuesday, Aug 12, 2003, at 14:42 Europe/London, James Strachan wrote:

> 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:
>>>> 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.
> Huh?

Sorry, didn't explain myself well on that one. The JMX spec dictates 
that a MBean exposes itself through an interface called XxxMBean. 
Therefore, if you also create interfaces/classes that end XxxMBean, 
it's not just a convention. It's the way it's done in JMX containers, 
and by virtue of ending interfaces in XxxMBean then (a) you allow that 
to be managed by a JMX container, but also (b) it may become dependent 
on a JMX container to run in. Further, external developers who see 
XxxMBean will assume that it is a JMX MBean, even if it isn't meant to 

If I had a class called SimpleSingleton, you'd be very surprised if it 
was a pop-up dialog box to ask for a file name. Names are just as 
important as the implementation, since it can mean something specific 
to developers. And the extension XxxMBean means a JMX managed bean.

>> True, which is why I suggested creating an MBean container to run 
>> within Geronimo.
> We've already got one - its in CVS.

Yes, I know, but I was suggesting that a J2EE server should be 
implemented as a MicroKernel architecture, and then (along with 
WebContainer and EJBContainer) provide an MBeanContainer for supporting 
legacy MBeans. That doesn't necessarily imply that everything needs to 
be an MBean, or that a J2EE server should be implemented using JMX, in 
much the same way that it wouldn't necessarily make sense to create a 
J2EE server that used Servlets for all of its implementation (though 
clearly, it could be done).

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

Neither JSR 77 or 88 say that the system must be implemented as MBeans 
though; they merely show a way of providing an MBean interface. As Greg 
suggested, these interfaces could be dynamically generated from XML 
files on top of implementations that are MBean agnostic.

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

I believe that the idea of Avalon as a Kernel is to sit under the JMX 
level, not on top of it. I don't see those as being implemented using 

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

They use it /because/ they implement JMX beans. It's not because it's a 
naming convention.

Of course, it's hardly surprising that mx4j uses a lot of MBeans -- 
after all, that is the Apache JMX implementation :-)

And, as already has been set, JBoss uses JMX MBeans for all of its work.

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

I never meant to imply that it was, nor that work could not start 
immediately on new services. Indeed, a few proposals have already been 
made that would (a) allow developers to get started on writing new 
services immediately, whilst at the same time (b) not being dependent 
on the MBean JMX spec/naming convention. At a later stage, ideas may 
surface for a replacement kernel, or they may never arise.

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

Absolutely agree.

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

I'd also agree with this as well.

But I think there is a happy compromise by providing some abstract 
classes (Service, ManagedComponent, whatever) that provide the MBean 
interface whilst allowing subclasses to be MBean agnostic. That way, we 
get the benefits of being able to develop (and run) stuff immediately 
whilst still initially using the MBean model, and then migrate as and 
when other kernels become available.


View raw message