geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject geronimo and avalon?
Date Thu, 07 Aug 2003 15:58:14 GMT
...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.

- 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.

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


cheers,

- Leo



Mime
View raw message