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 (http://ichilli.sourceforge.net/, 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 (www.enterpriseobjectbroker.org) 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 implementations).
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 out.
James ------- http://radio.weblogs.com/0112098/
