We actually use relatively little from Avalon other than lifecycle and configuration, both of which we could (and should in the latter case) replace. What little else we use from Avalon can be replaced by equivalents from Jakarta Commons, or developed locally (user and message stores). If we properly define our servicess as POJO interfaces, we don't need Spring. I would favor creating Geronimo GBeans to adapt between that container and our services.
I spoke with Jeremy and some other Geronimo folk about this, and it seems attractive since they have built a server framework as well.
I would only dispute the "if we properly define our services as POJO interfaces"... we do need to go with SOME container, don't we?
With respect to Groovy, I see that fitting into a startup role, and we should be open to seeing multiple technologies able to fill that role. It should not be a core technology.
Can you expand on the startup role you could see it serving?
-- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
