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:
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.
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.
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
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=trueThree dependencies are added into pom.xml file, although you may want to try out the latest plexus packages.
<dependency> <groupId>avalon-framework</groupId> <artifactId>avalon-framework</artifactId> <version>4.1.4</version> </dependency> <dependency> <groupId>org.codehaus.plexus</groupId> <artifactId>plexus-container-default</artifactId> <version>1.0-alpha-9</version> </dependency> <dependency> <groupId>org.codehaus.plexus</groupId> <artifactId>plexus-avalon-personality</artifactId> <version>0.13</version> <scope>runtime</scope> <exclusions> <exclusion> <groupId>plexus</groupId> <artifactId>plexus-container-default</artifactId> </exclusion> </exclusions> </dependency>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:
--./src/main/java/com/planetexpress/plexus2avalon/HelloWorld.java-- package com.planetexpress.plexus2avalon; public interface HelloWorld { String ROLE = HelloWorld.class.getName(); String sayHelloTo( String name ); } --./src/main/java/com/planetexpress/plexus2avalon/HelloWorldImpl.java-- package com.planetexpress.plexus2avalon; public class HelloWorldImpl implements HelloWorld { public String sayHelloTo( String name ) { return "Good news, " + name; } } --./src/main/resources/META-INF/plexus/components.xml-- <?xml version="1.0" encoding="UTF-8"?> <plexus> <components> <component> <role>com.planetexpress.plexus2avalon.HelloWorld</role> <implementation>com.planetexpress.plexus2avalon.HelloWorldImpl</implementation> <life-cycle-handler>avalon</life-cycle-handler> </component> </components> </plexus>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.
--./src/test/java/com/planetexpress/plexus2avalon/HelloWorldTest.java-- package com.planetexpress.plexus2avalon; import org.codehaus.plexus.PlexusTestCase; public class HelloWorldTest extends PlexusTestCase { public void testSayHelloTo() throws Exception { 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.
Comments