geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pasi Salminen <>
Subject Re: [services] getting service developers started - the initial component model
Date Tue, 12 Aug 2003 10:47:14 GMT

All that sounds reasonable and I fully agree with you. However, as the
project is still in early stages I'd like to emphasize the fact that J2EE
developers may want to deploy their own MBeans (doing things like flushing
a cache) also at runtime. This possibility is without doubt been forgetten
while WebLogic Server was coded. Even BEA WLS developers cannot supply one
with any reasonable ways to deploy your own standard MBeans which do not
have anything to do with WLS itself. And even if you can do it registering
those beans is next to impossible. You have to supply administrative user
and its password to WLS before you can register your own beans (due to
security issues). WebSphere handles this in much nicer way. One can embed
was.policy file into your application and the policy file contains grants
to do things. I know this is kind of future (and partly even security)
issue but I feel it's so important that I wanted speak it out now. It's
been a major show-stopper for deploying our own MBeans with application
servers and I've been doing tons of work due to this in order to make it
reasonable to deploy the same MBeans (part of our framework) to WLS and

Another thing which is really annoying in app servers is the fact that you
can't ask the name of the current J2EE application. That would help a lot
while creating a unique ObjectName for MBean which is instantiated and
registered at runtime (for example when the cache instance is registered by
the CacheManager or the bean itself). I just wonder why there's no API to
ask the name of the application in J2EE.?!?! I know that it's not J2EE
specified thing but it would be nice to be able to ask it without tons of
code (as I had to do in WebSphere).


Paci 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.
> 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
> -------


This message and its attachments have been found clean from known viruses 
with three different antivirus programs.

View raw message