Pico Container

# 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

## Unprocessed Properties

Properties are a powerful mechanism to add hints at registration time as to what the behavior of a component should be. It only works though when the right component factories are set for the container. Ones that recognise the property and can process it. For example, DefaultPicoConstructor's default constructor sets up an adaptive ComponentFactory that can handle HIDE_IMPL:

    pico = new DefaultPicoContainer();
    pico.as(HIDE_IMPL).addComponent(Apple.class);

But with a custom ComponentFactory, it may not:

    pico = new DefaultPicoContainer(new MyComponentFactory);
    pico.as(HIDE_IMPL).addComponent(Apple.class); // fails with PicoCompositionException

The trick is (in this case) to make sure that the right chain of component factories are setup:

    pico = new DefaultPicoContainer(new MyComponentFactory().wrap(new AdaptiveBehaviorFactory()));
    pico.as(HIDE_IMPL).addComponent(Apple.class); // fails with PicoCompositionException

A component may have many properties as it is added to the container. As each is processed, it is removed from the set. If there are any left after the component has been added the behavior or action that the property suggests has not been setup. Thus a PicoCompositionException being thrown warning of unprocessed properties only happens one or more properties are left - whether they are PicoContainer's own properties or custom ones