Avalon vs. PicoContainer or Spring
Looking for the best IoC container is not the purpose of this article. Well... there is no "the best" without conditions, which means the answer varies according to the project you are working on. Personally I found Avalon useful in several projects where the requirement and scope is extremely uncertain.
PicoContainer project has an article which outlines the difference between several popular ways of containing components
(not necessarily IoC containers). In general, comparing to the other options, Avalon depicts the lifecycle of a component elegantly and meticulously. And the compensation is to require the code to depend on its framework API.
Headache of Avalon? Simplified version of Avalon container that costs you less, Plexus
Assume you decide to take what Avalon requires and build the application on top Avalon API as I have done, the headache coming along is usally about:
- Maintain endless XML meta files for each componenent
- Building wierd .sar and .bar files
- Choose a non-embeddable container like Loom or something on top of Fortress
- Unit testing is doable but awkward
These issues stopped me from introducing Avalon to my manager for a while until Plexus project decoupled the Avalon personality
nicely in 2003. The decoupled personality made Plexus a slim version of Avalon container which doesn't require anything like meta file or .bar files. It only requires, by default, xml descriptors to define Avalon components
, similar to the bean definition xml file in springframework.
Start new project from scratch
Finally we can talk about code.
Step 1 is to create empty java project, com.planetexpress:plexus2avalon, with maven2 and add some dependencies into pom.xml.
mvn archetype:create -DgroupId=com.planetexpress -DartifactId=plexus2avalon
mkdir src/main/resources src/test/resources
vi pom.xml ##Add some dependencies described later
mvn eclipse:eclipse -DdownloadSources=true
Three dependencies are added into pom.xml file, although you may want to try out the latest plexus packages.
Step 2, write Avalon components. This is the most enjoyable part if you appreciate the effort made by Avalon. However I won't go into detail of how to write Avalon components
. Following interface, class and config is created:
public interface HelloWorld
String ROLE = HelloWorld.class.getName();
String sayHelloTo( String name );
public class HelloWorldImpl
public String sayHelloTo( String name )
return "Good news, " + name;
<?xml version="1.0" encoding="UTF-8"?>
Step 3, test it and start it. Plexus provides a base test case class which starts a testing plexus container instance during setUp(), and disposes it in tearDown(). Although instantiation of container in test case is considered as anti-pattern
and too integrated, I let it go in this example.
public class HelloWorldTest
public void testSayHelloTo()
HelloWorld hello = (HelloWorld) lookup( HelloWorld.ROLE );
assertEquals( "Good news, Fry", hello.sayHelloTo( "Fry" ) );
There are more work to do to finish this example. Like changing config to add the notion of Avalon personality
, since Plexus doens't know Avalon by default. This config change is required if you want to take advantage of the Avalon component lifecycle
, which could be the whole point of using Avalon. Please take a look at Plexus development guide
for more details.
Conclusion: It's really simple!
With Plexus Avalon personality, building components doesn't require anything but XML descriptor file. With a configuration hierarchy
, this work can be even simplified and distributed.