PicoContainer

# About

- What is PicoContainer?
- Introduction
- Javadoc
- Downloads
- News
- FAQ
- Project Goals
- Support

# Core Concepts

- Component Lifecycle
- Dependency Injection
- Scoped Containers

# Dependency Injection

- Constructor Injection
- Setter Injection
- Annotated Field Injection
- Annotated Method Injection
- Typed Field Injection
- Named Field Injection
- Method Injection
- Multiple Injection
- Composite Injection
- Factory Injection
- Reinjection
- Injection via Providers

# Configuration

- Disambiguation

# Modifying Component Behaviors

- Modifying Behaviors
- Caching and Singletons
- Hiding Implementations
- Thread Safety Behaviors
- AOP Style Interception

# Advanced Concepts

- Fluent Style
- Arrays, Collections and Maps
- Leveraging Parameter Names
- Building Containers
- Component Properties
- Component Configuration
- Monitoring Component Events

# PicoContainer's Architecture

- Design Patterns
- Inversion of Control
- Component Adapters
- Mock Objects
- Terminology
- Container Comparisons
- Transparency

# Container Choices

- DefaultPicoContainer
- CommandLinePicoContainer
- PropertiesPicoContainer
- SystemPropertiesPicoContainer
- TransientPicoContainer
- TieringPicoContainer

# Dependant & Related

- Web Frameworks
- Scripting Support
- Persistence
- Logging

# Anti-patterns

- Propagating Dependency
- Long Constructor Argument List
- Container Dependency
- Unit Tests Use Container
- Singleton

# Help Pages

- Ambiguous Injectable
- Unprocessed Properties

# History

- Inversion of Control History

# Project Info

- Project
- Team

# Hosted by

# Tools

## Component Lifecycle

Inversion of Control is three things: component dependencies and configuration, but also Component Lifecycle.

After instantiation, if the component warrants it, a 'start' stage may be required. More specifically, if a container has injected and instantiated all components in a set, one or more of them may require starting in the same order they were instantiated. Later, in reverse order, the same component(s) may require stopping. In fact start and stop may happen more than one for the life of an application. Disposal may happen once only, before the component is eligible for garbage collection.

Lifecycle is really only going to work for PicoContainers that are also caching component instances. Caching was a default in PicoContainer 1.x, but is not for 2.x - be warned!

Thus lifecycle implies three methods:

- start
- stop
- dispose

In PicoContainer we think allow a pluggable LifecycleStrategy.

### Startable

Our own interface for startable. We wish it were in the JDK, because we're big into making components unencumbered by the trappings of containment. In English: we'd rather not make components implement/extend/throw anything from our framework. Its a 'transparency' thing.

Here's an example of components fitting that ideal

    public class Apple implements Startable{
      public void start() {
        // listen on socket, start thread etc.
      }
      public void stop() {
        // stop listening on socket, kill thread etc.
      }
    }

    ...

    pico = new DefaultPicoContainer(new StartableLifecycleStrategy());
    pico.addComponent(Apple.class);
    pico.start();
    // start gets called

    Apple a = pico.getComponent(Apple.class);

The StartableLifecycleStrategy can be extended if you prefer your own interface for Startable. Just override

### Reflection based start/stop/dispose

This works without an interface. Instead it works via reflection, and appropriate method names.

    public class Apple {
      public void start() {
        // listen on socket, start thread etc.
      }
      public void stop() {
        // stop listening on socket, kill thread etc.
      }
    }

    ...

    pico = new DefaultPicoContainer(new ReflectionLifecycleStrategy());
    pico.addComponent(Apple.class);
    pico.start();
    // start gets called

    Apple a = pico.getComponent(Apple.class);

If you have other synonyms for start/stop/dispose, just extend the ReflectionLifecycleStrategy class and provide them.

### Java EE 5 annotation based start/dispose

This works without an interface, but with annotations in front of the designated methods

    public class Apple {
      @PostConstruct
      public void startUp() {
        // listen on socket, start thread etc.
      }
      @PreDestroy
      public void allOver() {
        // stop listening on socket, kill thread etc.
      }
    }

    ...

    pico = new DefaultPicoContainer(new JavaEE5LifecycleStrategy());
    pico.addComponent(Apple.class);
    pico.start();
    // start gets called

    Apple a = pico.getComponent(Apple.class);

These annotations are supplied with Java 6, but come in a jar for Java 5 and below. See http://mvnrepository.com/artifact/javax.annotation/jsr250-api

### No Lifecycle

DefaultPicoContainer does sets StartableLifecycleStrategy by default. You can specify NullLifecycleStrategy instead if you are sure that no components honor any lifecycle concept..

### Custom Lifecycles

Write a class that implements LifecycleStragegy, there are just four methods to implement. See LifecycleStrategy.

### Where Next?

The Disambiguation page outlines strategies
for dealing with choosing which of two
potential injectables for one component