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 be.
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 JMX.
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.
Alex.
