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 kernel.
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).
-dain
