On Tuesday, August 12, 2003, at 10:00 am, Alex Blewitt wrote:
On Tuesday, Aug 12, 2003, at 07:07 Europe/London, [EMAIL PROTECTED] wrote:
I'm sure we could all debate the perfect container framework and compare and contrast the intricacies of the various flavours of Avalon containers, PicoContainer, JMX & Java Beans until the cows come home. However what is really important right now is we start writing lightweight, pluggable services ASAP to start filling in the J2EE stack for Geronimo.
Definitely concur with this one.
So initially I think the component model should be JMX MBeans. These are simple, lightweight components that have no compile time dependencies on anything. The MBeans themselves should follow the Inversion of Control pattern - i.e. the container instantiates & configures the MBean. In addition we should try follow the MBean interface pattern such that we can do efficient interception easily with dynamic proxies - also note that MBeans do not need to use JMX at all - any container mechanism can be used to configure & wire together the components.
The only problem with this approach is that there isn't a suitable abstraction layer in the Geronimo kernel to allow for easy refactoring at a later stage.
I think you're missing the point I'm making - more below...
It would be much better, for example, to create an interface called 'Service' (for example) that implements MBean initially, but ensure that any code written for Geronimo doesn't depend on MBean. That way, refactoring at a later stage will be much easier.
Having the Geronimo container depend on JMX is not the issue. Its what should component developers depend on. I'm saying - have no dependencies (not even JMX) just write interface based MBeans which are not dependent on *anything*...
Already today Geronimo can handle MBeans. It must always be able to handle MBeans. Indeed whatever Geronimo's container framework becomes it should be easily cable of working with the plethora of J2EE MBeans that are out there. (MBeans are essential to J2EE).
I've not found the section in the spec that says this.
Have you read JSR 77 and JSR 88?
So in summary
* lets start writing J2EE services as MBeans that we can plug into Geronimo today.
I think the more services that are created sooner, the better. However, I would strongly suggest that we create an abstraction API that we can use in Geronimo to make the services available, that decouples the implementation of the services from JMX sooner rather than later.
Like I said - we don't need an abstraction API. An MBean interface has no dependencies on JMX.
Otherwise, if we write and build heavily on the assumption that everything-is-an-MBean then it will be a lot more difficult to change/remove that assumption later on. A few abstract APIs would solve this problem immediately.
Why - an MBean (interface) is just a POJO with an interface. Why should we make component authors dependent on yet-another-abstraction-API when we don't need to?
* in parallel to this activity folks can help improve & innovate inside the Geronimo kernel - without adversely affecting the progress of the component authors - we can all work in parallel
Absolutely. In fact, it would be great if there was an 'experimental' spike doing this now, either by having a set of packages in the Geronimo core, or a different module, or a different CVS tag to allow this to occur in parallel now. However, since most of us don't have commit privileges, (and thus can't control the experimental/head checkins) it might be more advisable to have an experimental package/module, which would then fit in with head
There are already many MBeans in the CVS repository. Go take a look. Search for files matching *MBean.java.
* those Avalon fans could package up one or more Avalon containers as MBeans then any Avalon components could be easily deployed inside an actual Avalon container inside Geronimo. Ditto for PicoContainer too. i.e. this strategy allows for a diversity of containers to be > deployed.
This still doesn't address the heavy coupling of the entire framework to MBeans/JMX,
There is no heavy coupling. How the MBeans get used and whether or not JMX is used is purely internal to the container.
which is essentially the point I'm making. It would be more sensible, for example, to build an Avalon framework kernel that could allow legacy MBeans to be instantiated.
I disagree that this is more sensible. I'm not ruling it out in the future - but what is sensible is today using the JMX kernel we have today and creating the necessary J2EE services in accordance with the full J2EE 1.4 spec (which includes JSR 77 & 88).
When we have a plethora of services all following all of the J2EE specifications for management, deployment, classloading and so forth then Avalon folks will have a chance to demonstrate how Avalon could implement the core container better than the one we've got. Until then - lets focus on getting the services integrated in the simplest, loosest coupling way forward.
* once all the required deployment options are available (EAR, WAR, SAR) and the ClassLoader stuff is working along with the interceptor stack; folks can then refactor the container using some real J2EE services to improve the manageability & codebase - based on real refactoring of working code rather than too much up front design. Indeed we can take a TDD approach to refactoring the container. So rather than guessing what a J2EE container should look now, we can refactor as we get there to improve it.
And one of the goals about refactoring is to set up easier migration paths. Importantly, refactoring can be done at any time, and abstracting/decoupling the implementation from JMX (wherever possible, not necessarily as a major rewrite) will aid in that.
JMX is only used inside the container right now. Its hidden inside the container - so can easily be refactored later. There is no JMX in the components.
So I'd suggest creating abstract interfaces (Service, Container etc.) that developers can write to, and not MBeans. (However, the Service can initially implement an MBean to facilitate migration.)
We've already got that in CVS though its use is totally optional to component / service authors. Also following JSR 77 for lifecycle APIs is probably a good idea going forward too.
* we should make great progress, getting J2EE coverage fairly soon - yet we won't really be tied to JMX at all - the MBeans could be used in any container implementation.
Again, the J2EE spec in no way requires MBeans to be used as the container implementation.
Please double check you table of contents of the J2EE specification.
Indeed, the spec is specifically implementation agnostic on this and almost all other points regarding implementation of containers. I'd find it quite unlikely that an implementation of something built for one server (e.g. WebLogic/WebSphere) would stand a chance of running in another (e.g. JBoss, Geronimo).
Building everything now implementing MBean is a sure way to be tied to JMX. Building an abstract API for Geronimo is a sure way to allow things to be changed later.
No its not!
* if in the future we come up with some other component model to be supported, it should be trivially easy to plugin MBeans anyway, or a simple refactor to support them
Why do we need to support plugging in of MBeans?
Because JBoss, Tomcat, Jetty already do this and we want to reuse their MBeans. Also because our codebase already does this. Thirdly because there's a plethora of reusable MBeans out there that just drop into containers like JBoss.
I challenge the notion that MBeans are even a necessary part of this implementation. It should be an externalised API, using the Facade/Bridge patterns, not everything-must-be-an-mbean.
Point taken - though you're still missing my point - using MBeans does not mean we must use JMX.
Thoughts?
I agree with your main point of this message; that there is an initial code base, and that 'purist' views may not be helpful for moving the project forward quickly.
I also agree that the sooner there is a framework to allow new code to be written, the better.
There already is - its in CVS.
I disagree that everything-must-be-an-MBean, and I also disagree that the J2EE spec has anything to say on implementational aspects using MBeans.
I disagree that a J2EE server must be an MBean container.
I believe that an approach where everything-is-an-MBean introduces unnecessary high coupling between the application server and the components within. I also assert that if many services are developed that directly are MBeans, then it will be much more difficult (to the extent that it becomes impossible) to refactor out these dependencies later on.
In short, I believe that to keep our options open for longer, and to support migration away from a JMX kernel later on, we should introduce abstract types/interfaces/classes to represent the generic components within Geronimo. Then services should be written entirely in terms of this abstract API and not depend on JMX at all.
This will allow initial code to be developed and the project moved forward, and alternative approaches for managing the Service or Container APIs can be developed in parallel, rather than a big refactoring initially that holds up the development of new services.
Rather than repeating myself again I'll just conclude with - by using pluggable MBeans we're not tying ourself to any particular server framework - not even JMX. An MBean can be used inside Geronimo today as well as in PicoContainer or in an Avalon container with some adapter layer or some-other-container-not-invented-yet.
In this thread - please take off your container developer hat and put on your service developer hat. In this thread I was purposely not discussing the container at all. I was discussing what component authors should do. The container should be totally invisible from a component developers perspective, then IoC and the container does the rest. If you don't believe me - look at some MBeans or PicoContainer components.
The only API that might be a possible container API for component developers could be a lifecycle interface in Geronimo - or using JSR 77's lifecycle API which if the latter works I'd prefer then component developers are only dependent on J2EE APIs and so their code runs in any container, not just Geronimo.
James ------- http://radio.weblogs.com/0112098/
