geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James deGraft-Johnson" <>
Subject RE: [services] getting service developers started - the initial component model
Date Tue, 12 Aug 2003 07:47:10 GMT

I am joining this effort with the hope of being a code contributor.

I think this (MBean component model) is a good idea. It would be helpful if
a sketch or example MBean can be created, so those of us who are new to open
source development and MBean development can understand exactly what this
component model entails. (This example does not have to be throw-away as it
could be a live component.)

There are two other suggestions I would like to make. One is that a decision
on the base (kernel/framework) code be made and moved to CVS assuming it
hasn't already. Also, whatever this MBean component model involves, it
essential that we move ahead to porting the existing containers/services to
this model to identify any risks in the approach we are taking.

James deGraft-Johnson
3419 Hampton Hollow Drive, Apt G,
Silver Spring MD 20904.
Tel:        (301) 847-1694
Fax:        (301) 847-8025
Mobile:  (240) 475-1444 (

-----Original Message-----
From: [] 
Sent: Tuesday, August 12, 2003 2:07 AM
Subject: [services] getting service developers started - the initial
component model

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.

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



View raw message