XDoclet 2 - Picocontainer and its relevance to XDoclet2

Picocontainer and its relevance to XDoclet2

At the heart of XDoclet lies Picocontainer. Picocontainer, henceforth referred to as 'Pico', is a Dependency Injection (DI) container like Spring-core. For Pico to manage bean dependencies for us, they need to be registered with the container first, the container then wires up the dependencies. Pico does not seem to allow us to specify the bean configuration in an xml file unlike Spring Framework. Dependencies can be specified in java source code through pico APIs though. Contrary to popular belief, Pico supports 'setter injection' in addition to 'constructor injection'. Pico developers prefer the latter though. One might argue as to how significant or otherwise that is. If you are looking for Spring-like configuration file support, then Nanocontainer is the project to look at.

All DI containers support some minimal life cycle methods and so does pico through LifeCycle APis specified through interfaces. The life cycle in turn is managed internally by the container through callbacks. The bean-writer typically lets the container invoke the callbacks by implementing the interface - org.picocontainer.Startable .

public interface Startable{
  public void start(); 
  public void stop(); 
 }

Typically, when using Pico with life cycle support, you do the following -

1. Instantiate the container and register the beans with it.

The following class subscribes to Pico lifecycle methods -

import org.picocontainer.Startable; 

public class Ferrari implements Startable{

  public void accelerate(){
    System.out.println("Ferrari is on its way!..");	
  }
			
  public void halt(){

  }		

  public void start(){
    accelerate();
  }
		
  public void stop(){
    halt();
  }	
}

The following code registers the classes Ferrari and Toyota( another class with a similar implementation as Ferrari), with the container.

import org.picocontainer.MutablePicoContainer;
import org.picocontainer.defaults.DefaultPicoContainer;

public class FormulaOneRace{

 public static void main(String[] args){

  //instantiate the container
  MutablePicoContainerformulaOneContainer=new DefaultPicoContainer();

  //register the beans that you want managed by the container
  formulaOneContainer.registerComponentImplementation(Ferrari.class);
  formulaOneContainer.registerComponentImplementation(Toyota.class);

  //start the container. Pico will look for all beans that implement
  //Startable interface and call start() on each of them.

  formulaOneContainer.start();
 }
}

2. Start Pico by invoking pico.start() method.

On start(),

the container wires up all the dependencies for all the registered components and

//@TODO will be good to change the example to demonstrate some basic DI

by default looks for components that implement Startable interface and invokes the 'start' method on them. Running the above class FormulaOneRace, produces the following output :

$ javac FormulaOneRace.java

$ java FormulaOneRace
Ferrari is on its way!..
Toyota is on its way!..

There is a little more to the way pico handles the bean-sequence in which lifecycle methods are invoked but for now its important to note that the order in which the beans were registered is honoured when calling start. In the context of the race, it's probably unfair though that Ferrari got to get off the blocks first.

Similarly stop() will be called on the components when Pico is explicitly stopped through pico.stop().

XDoclet2 employs the simple lifecycle support (through Startable interface) of Pico. This concludes the short primer on Picocontainer. Now that we have a basic understanding of Pico, let us try to understand what Generama is.

User Documentation

IDE Integration

Maven Integration

Plugins

Project Information

Developer Documentation

Feeds

Picocontainer and its relevance to XDoclet2