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 11:27:34 GMT
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. 
Changing things after they've been done is much more difficult than 
before they've been done :-)

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

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.


View raw message