Avalon is Apache's Java Server Framework project. It is separated into six subprojects: Framework, Excalibur, LogKit, Cornerstone, Phoenix, and Apps. Its purpose is to simplify server side programming for Java-based projects. It formalizes several best practices and patterns for server side programming. Framework describes the interfaces and contracts for the component-based architecture. Excalibur provides a number of useful components and utilities. LogKit is a logging implementation. Cornerstone is a group of reusable server components and services. Phoenix is an enterprise container implementation that uses all of the other subprojects to automatically deploy and manage one or more componentized servers. Apps is a home for several Phoenix-compatible server applications and reusable components (like FtpServer).
Re: Death by software engineering
> I have some major problems with
> It creates way too much indirection.
> The Avalon way is that everything but
> everything is named in a config file and
> loaded dynamically, including the things
> that are named in the config file,
> including the things naming the things
> naming the things. Navigating source of
> Avalon-heavy projects is an endless
> scavenger hunt. Wrappers are fine, but
> once your wrappers have wrappers it's
> time to stop.
Not everything in Avalon is like that. Perhaps
you are referring to the LogKitManager? You
are not required to use configuration files at all,
but they do help tremendously if (as you say)
you need to get in and get out quickly.
Could you list the Avalon projects you have
personally been in contact, and give a more
concrete example? I find that approach works
more to help me understand what you are
> Learning curve:
> Avalon documentation on Apache is all
> prose, no Javadoc. Go ahead and check
> it out at
> That's all you get. Furthermore the
> prose is long winded (50 pages) and
> philosophical rather than quick and
> clean. So the only way to interact with
> an Avalon project is through a personal
> committment to learn a whole new
> framework. Learning new frameworks is
> fine, but often way more overhead than
> necessary. A primer and Javadoc are
> badly needed.
:/ I've actually been complimented on the
"Developing With Avalon" (http://jakarta.apache.org/avalon/developing-with-avalon.pdf) documenation (50
pages). Many people find that the primer helps
with getting in the mindset of Component
Javadocs are there, but perhaps the links could
be more prominent. We have Javadocs, and
UML diagrams. Check the navigation links,
ther are there.
> Avalon touches every module in a
> system and works its way into every nook
> and cranny of the source. This is the
> opposite of modularity. Once you get
> married to Avalon, there is no
Honestly, I find it a good marriage. If you don't
want to implement the lifecycle interfaces (as
I think that is what you are getting at), you can
use AspectJ to do it for you.
All of the Management is moved to the
Container of the Components. This is as it
should be. All components can focus on being
components--without too much inderection.
> The net effect of these problems is
> that it is impossible to have casual
> contact with the source of an Avalon
> application. Either you join the Avalon
> religion - and it's more Hare Krishna
> than Unitarian - or you go somewhere
> else. That is bad anywhere, but
> particularly in an open source project,
> where many developers need to get in and
> out quickly.
I honestly don't get the analogy here.
Instead of posting these comments on
Freshmeat, perhaps you should subscribe to
the list, and we can work through what your