Up to now the Geronimo codebase has assumed a JMX micro kernel, following in the footsteps of JBoss, Tomcat 5 and Jetty. I'm sure this can be improved with time though this strategy has been proved to work. Before we get bogged down in months of upfront design for what the perfect container should be - I'd like us to be able to make good progress integrating the various services - of which there are many. Then we have some real use cases that can help us as we refactor the Geronimo container.
What I'd like to do as an initial step is choose a default component model for service developers to follow as they write Geronimo services. For some time most of the main services in Geronimo are going to be fairly course grained (web container, Axis, JMS provider, JTA etc). In addition at the time of writing Geronimo can deploy MBeans.
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.
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).
So in summary
* lets start writing J2EE services as MBeans that we can plug into Geronimo today.
* 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
* 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.
* 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.
* 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.
* 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
Thoughts?
James ------- http://radio.weblogs.com/0112098/
