geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: geronimo and avalon?
Date Thu, 07 Aug 2003 16:34:00 GMT
Thanks Leo for a good email...

On Thursday, August 7, 2003, at 04:58  pm, Leo Simons wrote:

> ...not right now, I think. Here's some more thoughts on that.
> Hey gang,
> okay, okay, I can't resist throwing in a few words about this. I've 
> been an avalon committer for several years now, and I've used it for 
> many if not all of my software projects ever since becoming 'infected' 
> by it. So I am probably way biased.
> Why build on avalon
> -------------------
> One answer: it's a solid, tried and tested Apache project with a lot 
> of mature, tried and tested code and concepts that have been proven to 
> work well in environments ranging from embedded devices to oracle 
> clusters.
> Another answer: it already integrates with a lot of projects that are 
> likely to be on the shortlist for integration with Geronimo, like
> * OpenEJB (drag-and-drop runs on top of avalon-phoenix (and 
> avalon-merlin))
> * Jetty and Tomcat (drag-and-drop run on top of avalon-phoenix (and 
> avalon-merlin))
> * James (has always run on top of and shipped with avalon-phoenix (and 
> runs on avalon-merlin as well))
> * HSQLDB (drag-and-drop runs on top of avalon-phoenix)
> * several of the other important enterprise technologies can be added 
> in as well rather easily if not out of the box, for example Axis 
> (through the Ivory wrapper)
> * MX4J (avalon-phoenix has builtin JMX support through MX4J)
> * Log4J (avalon-phoenix can be configured to use log4j)
> * Xerces (avalon-framework has an xml-based configuration system that 
> usually is coupled to xerces)
> another answer: avalon is all about server software architecture, and 
> the general approach offered by the patterns it promotes (COP, 
> Seperation of Concerns, Inversion of Control) is hands down the 
> cleanest and most reliable way to build complex software. Those 
> approaches are implemented well throughout avalon code. Really well.
> Sounds compelling, doesn't it? So much so, in fact, someone did so for 
> his graduation thesis (, code not 
> public though).
> Wny not build on avalon
> -----------------------
> - While all those important components listed do integrate with avalon 
> easily, they're for the most part not actually built with avalon 
> (James being one notable exception).
> - Avalon is at the moment a relatively small project (somewhere around 
> 20 committers I think) compared to what Geronimo is likely to be in 5 
> months; it might be just as easy to just fork and/or rewrite it and 
> not have such a big dependency at the very core of a project. (IMHO, 
> one of the reasons for avalon never being used internal to tomcat. 
> That, and several tomcat peeps disagreeing with some avalon design 
> decisions).
> - the current list of committers for geronimo doesn't include many 
> people that have lots of experience with avalon, while there is a lot 
> of people with experience in doing things differently (ie JMX-based 
> like JBoss)
> - Avalon has a relatively high learning curve. To gain all the 
> cleanliness it provides, its security and its stability you need to 
> know how to use it well; getting to grips with an IoC (Inversion of 
> Control) setup is way more difficult at first than getting to grips 
> with a central-registry style approach (JNDI, JMX, etc).
> - Avalon imposes strict contracts. You have to do lots of stuff in the 
> way the avalon design dictates you to. (well, usually, you don't, 
> really, but most peeps, including avalon regulars, disagree with me on 
> that :D)
> - a lot of the avalon folk have always complained heavily about the 
> limitations of EJBs, so much so in fact that they have written an 
> avalon-based alternative ( to show how 
> much better the world is without EJB.

AFAIK the EOB project is now moving towards using PicoContainer rather 
than Avalon.

> - the avalon mindset seems to behave rather virally. Once people 
> become convinced that IoC is the way to go, they never go back.
> - there is already an initial codebase that doesn't use it, and we 
> want to go forward with that. Refactoring around avalon would delay a 
> first release by miles.
> Conclusion
> ----------
> Nope, no conclusion. Well, the only significant one perhaps is that 
> building a J2EE suite on top of the framework avalon provides is 
> definately possible. I am not going to get mingled in the debate of 
> whether that is a good idea (me, I think a JMX-based microkernel 
> remains a bad idea, even though it is working so well for JBoss. But 
> that's just me ;).
> Just know some of the avalon regular are listening in with an 
> interested ear to hear what's all the fuzz about ye olde Indian war 
> chief, and we're more than willing to help you evaluate what stuff (if 
> any) you want to use from the avalon project. And we can probably 
> leave y'all completely alone, too, if desired ;)
> Deal with the big things first
> ------------------------------
> I suggest everyone waits for a few weeks 'till the first bits of code 
> are here, knowledge has been gained and the project has been 
> 'bootstrapped', before raising the topic again. I don't think its 
> healthy (and I mean for geronimo *and* avalon, in case anyone wonders) 
> if people go saying "geronimo really should use avalon" nor "that is 
> absolutely out of the question" before you guys get some other things 
> settled first. You can always change your mind later.

I've tried to reflect this in the FAQ.

> But again, that's just me, known for being off the mark :D

You're totally on the mark.

At this point we're not ruling nothing in or out - just requesting some 
time to grow & decide.

We're  in the middle of building a special kind of container, Geronimo. 
  Given time, Geronimo could end up being an Avalon container. Or it 
could have an optional Avalon module so some adapter/service could 
allow any existing Avalon container (or PicoContainer) to drop right in 
and so it could end up reusing any of the plethora of containers out 
there (off the top of my head there is... Phoenix, Plexus, ECM, 
Fortress, Merlin, Loom, DNA, JContainer, PicoContainer, NanoContainer - 
which are all different Avalon, ex-Avalon or PicoContainer 

I'm pretty sure we'll eventually support (somehow) Avalon & Pico 
components in some way. Interoperability is a goal. Lets just leave the 
implementation time to grow first and make decisions based on whats 
best for Geronimo the container. JMX, Avalon and Pico are 3 component 
models I'd like us to support - lets keep the container open first 
though until it gets the basic requirements (JTA, EJB, MDB, Web) sorted 


View raw message