geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <james_strac...@yahoo.co.uk>
Subject making JSR 77 / 88 reusable for component authors (& container developers)
Date Wed, 26 Nov 2003 16:42:39 GMT
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.

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/


Mime
View raw message