Avalon
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).
| Tags | Software Development Libraries Application Frameworks |
|---|---|
| Licenses | Apache |
| Operating Systems | OS Independent |
| Implementation | Java |
Recent releases
- 24 Apr 2003 03:28
Changes: Excalibur-Thread was upgraded to 1.1 and the method for specifying JNDI naming handlers in the kernel was improved.
- 16 Sep 2002 19:50
Changes: In this release, MX4J (JMX) is loaded by default. Beanshell kernel capability has been . XDoclet has been improved for JMX manifests. Block-initiated shutdown support has been added.
- 16 Sep 2002 00:41
Changes: This version adds SMTPOutputLogTarget to enable logging to email addresses, includes several bugfixes, changes the default log format so that the log entry times are formatted using a human friendly format, rotates logs before write, and adds RotateStrategyByDate to enable daily, weekly, and monthly rotation of log files.
- 12 Aug 2002 20:07
Changes: JMX capability via the embedded MX4J application.
- 09 Jul 2002 15:59
Changes: Minor bugfixes, updates to documentation, and removal of some deprecated functionality.
- All comments
Recent commentsRe: Death by software engineering
> I have some major problems with
> Avalon.
>
> Navigation:
> 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
getting at.
>
> Learning curve:
> Avalon documentation on Apache is all
> prose, no Javadoc. Go ahead and check
> it out at
> http://jakarta.apache.org/avalon/framework/
> 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
Oriented Programming.
Javadocs are there, but perhaps the links could
be more prominent. We have Javadocs, and
UML diagrams. Check the navigation links,
ther are there.
>
> Modularity:
> 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
> divorce.
>
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
problems are?
Death by software engineering
I have some major problems with Avalon.
Navigation:
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.
Learning curve:
Avalon documentation on Apache is all prose, no Javadoc. Go ahead and check it out at http://jakarta.apache.org/avalon/framework/ 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.
Modularity:
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 divorce.
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.