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.
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).
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.
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.
i.e. if you just want a container & don't want to be part of the Geronimo J2EE stack but want to plug, say, transactions in your own way, go for it - use a simpler container and your own custom AOP or interceptor hooks or whatnot.
However if you want a container designed with all the J2EE hooks in mind, to all the common J2EE services stack (transactions, security, locking, remoting, WS and so forth) as well as support for all the main J2EE service implementations, then try using Geronimo.
From a component developers perspective none of this should matter - its just a deployment issue. The user of your component gets to decide where your components are deployed & in which container (some simple lightweight one, or full J2EE certified Geronimo).
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.
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?
James ------- http://radio.weblogs.com/0112098/
