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.
