geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: making JSR 77 / 88 reusable for component authors (& container developers)
Date Sat, 29 Nov 2003 23:08:10 GMT
On Wednesday, November 26, 2003, at 10:42 AM, James Strachan wrote:

> I ended up rambling on about this with Noel on the members list & we 
> wanted to repost our thoughts here - where these kinds of discussions 
> belong.
> On 26 Nov 2003, at 02:34, Noel J. Bergman wrote:
>>> Also I hope that as different components become integrated into
>>> Apache's J2EE stack it should be easier to install, configure & 
>>> manage
>>> all of these components in a cleaner way thanks to JSR 77/88.
>> I am wondering if there might be some code in Geronimo that could be
>> factored out as general JSR 77/88 container code.
> Its kinda already like that - the kernel & core of Geronimo is mostly 
> that; though maybe better/more refactoring is possible.

I needs some more refactoring, but it is already a small reusable 

> Certainly I think we should be able to define the container-component 
> contract which could be as simple as 'write a POJO', or 'have 
> start/stop methods' for a simple 1 node component (i.e. not a tree of 
> things) or for more complex trees of related components, 'have say 5 
> methods, start, stop, startRecusive, ... etc' or 'implement interface 
> GeronimoLifecycle'  or whatever. So there can be levels of > integration.
> Certainly the component/service contract should be refactored out & 
> documented so that anyone can write compatible components. (It could 
> well be that there's no actual code dependencies, just a coding 
> convention - or we could have a super tiny jar of 1 interface and 1 
> base class folks could derive from if they wish to take part in the 
> JSR 77/88 lifecycle - which is optional, depending on the complexity 
> of the component).

It is all naming convention, but I have an easy interface that give you 
compiler time checks.

> I'd rather delay (or even postpone indefinitely) the refactoring 
> geronimo into *just* a 77/88 container and a separate j2ee container 
> just until things settle down a little. Whats happening at the moment 
> is folks are figuring out, after 77/88 and the various J2EE APIs (like 
> JNDI, JMX, JTA) what other hooks would be useful to be exposed for 
> closer integration between, say, JOTM and OpenJms or Axis and JOTM > etc.

Too late it is already separate.

> Depending on what these hooks are & how interdependent the interceptor 
> stack is, it might be there's little point ever refactoring out 77/88 
> from Geronimo as the core container might be kinda J2EE specific (if 
> you see what I mean). However there's no reason why the 77/88 hooks & 
> conventions used by Geronimo couldn't be adopted so that Avalon's 
> containers, Spring, PicoContainer (& all the others I forget) couldn't 
> become JSR 77/88 containers too - maybe without the J2EE/Geronimo 
> hooks for security, transactions & remoting.

Most of the components should work as is with PicoContainer and I think 
with a small adapter they should work in ObjectWeb Fractal.  I don't 
know anything about Spring or what Avalong does.  Currently there are a 
few JMX things, like needing an mbean server to register for events, 
and there are a few features custom to geronimo, like the ability for a 
component to signal to the server that it has failed or wishes to stop.

>> I'm also thinking that
>> Avalon should add JSR 77/88 support so that any complant component 
>> can be
>> plugged into an Avalon container.
> Absolutely.
> There's no reason why Avalon containers can't be plugged into Geronimo 
> too; either as one big-ass component - or preferably as a tree of 
> components following the same integrated JSR 77 / 88 mechanism.
> Refactoring out the 'component developer contract' from Geronimo so 
> there's clear guidelines on how to write Geronimo/77/88 compliant 
> components is a big win-win. The more reusable components for Geronimo 
> the better.

I can see wanting to reuse components written for Avalon without 
rewriting, but unless there is an Avalon kernel service not present in 
Geronimo, I don't see why you would want an extra container layer.  I 
don't know Avalon, but assuming it is a micro kernel, any service that 
a component depended on from Avalon *should* be able to run in Geronimo 
without the entire Avalon stack.

> e.g. describing the 'GBeans' part. (I dunno if GBeans has taken off 
> yet as a term - its short for 'Geronimo Beans', I started using it at 
> ApacheCon hoping it'd take off - essentially the "Geronimo MBeans" 
> folks kept talking about, which we not necessary MBeans, so wanted us 
> to stop calling them "Geronimo MBeans" - if all of that makes sense).
> I guess the wiki's a good a place as any to start describing what it 
> takes for component author to write components for Geronimo? Then 
> as/when we need to we could refactor out some core bits and pieces 
> into a tiny jar that folks could, optionally use, if they want to 
> develop components with seamless & close integration with Geronimo (if 
> they wanna be typesafe rather than following a coding convention). I 
> suspect a coding convention might be more popular with component 
> developers?

I hope to get the code cleaned up and documented soon (maybe with some 
help from David Jencks).


View raw message