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

## Scoped Containers

PicoContainer's scope hinges on parent/child container relationships. From a PicoContainer instance you can make a child container via makeChildContainer() or addChildContainer(..).

These hierarchies of container can be set up with parents and children refering to each other, or children referring to parents only, or parents referring to children only. This changes the way that things work considerably. If a child has its parent registered, then it can lean on it for component resolution (but not without). If a parent has its child registered asa child, then it can manage it (start, stop, dispose cascade into children).

Web frameworks that leverage PicoContainer typically construct a tree of containers. For example an application level container maintains components that can be shared across the application. The application container will have child containers to maintain session level components. These session level containers can resolve dependencies through their parent containers, but the application container will have no visibility into its children. Additionally these child container do not have visibility into their sibling containers. With this design, containers can easily be garbage collected at the end of their scope.

## Simple Examples

Here are examples of parent/child setup:

    parent = new DefaultPicoContainer();
    parent.addComponent(Apple.class);
    parent.addComponent(Orange.class);
    parent.addComponent(Pear.class);
    child = parent.makeChildContainer();
    child.addComponent(DependsOnApple.class);
    // this is OK
    parent.start();
    // cascades to child just fine

    parent = new DefaultPicoContainer();
    parent.addComponent(Apple.class);
    parent.addComponent(Orange.class);
    parent.addComponent(Pear.class);
    child = parent.addChildContainer(new DefaultPicoContainer());
    child.addComponent(DependsOnApple.class);
    // this is NOT OK. child can't see parent
    parent.start();
    // cascades to child just fine

    parent = new DefaultPicoContainer();
    parent.addComponent(Apple.class).addComponent(Orange.class).addComponent(Pear.class);
    child = parent.addChildContainer(new DefaultPicoContainer(parent));
    child.addComponent(DependsOnApple.class);
    // this is OK
    parent.start();
    // cascades to child just fine

    parent = new DefaultPicoContainer();
    parent.addComponent(Apple.class).addComponent(Orange.class).addComponent(Pear.class);
    child = new DefaultPicoContainer(parent);
    child.addComponent(DependsOnApple.class);
    // this is  OK
    parent.start();
    // does NOT cascades to child

There is no limit to the extent of the chained containers, for example - great grandparent, grandparent, parent, child, is OK.

Garbage collection is the standard way of disposing of scoped containers. If the children refer to the parents, then assign child to null just works. If the parents refer to the children too, then you'll have to do a removeChildContainer(..) first before it will be eligible for garbage collection.

See web frameworks also.