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.
Huh?
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 *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.
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 others.
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.
So?
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 requirement.
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.
James ------- http://radio.weblogs.com/0112098/
