geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <Alex.Blew...@ioshq.com>
Subject Re: Kernel Architecture
Date Tue, 12 Aug 2003 13:17:24 GMT

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.

>>>> 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 *MBean.java)
>>
>> 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.

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

Alex.


Mime
View raw message