Skip to end of metadata
Go to start of metadata

Authors: Aslak Hellesøy, Jörg Schaible

Supported Collective Types

PicoContainer supports injection of collective types. These are native Arrays, Collections and Maps. Components depending on types implementing these interfaces can be provided automatically with such an instance. Since for native arrays the type can be determined at runtime, this can be done quite automatically, for the other types a special parameter must be provided. For the examples we use following classes (just ignore the fact that the classes are static):

Arrays

PicoContainer can create a native array of components of a specific type automatically. Example code for the Bowl class in use:

Example usage:

PicoContainer will instantiate the arrays and populate them with all components that matches the array type. Behind the scenes something similar to the following is happening:

Collections

PicoContainer supports automatically generated Collection types. Example code for the Bowl class in use:

Unfortunately there is no way of detecting the type of the components being part of the collection as it is done for native arrays. Therefore you must use a special constructor of ComponentParameter and define the component's type:

The boolean argument defines, that the Collection cannot be empty. Also look at the constructor of the Bowl class. You can use a specific class implementing the Collection interface or just the interface itself and PicoContainer will provide a matching Collection instance.

Maps

PicoContainer also supports automatically generated Map types. Example code for the Bowl class in this case:

As for Collection types, PicoContainer cannot detect the type of the components, that should be part of the collection on its own. Again you must use a special constructor of ComponentParameter and define the component's type:

The boolean argument defines, that the Map cannot be empty. Also look at the constructor of the Bowl class. You can use a specific class implementing the Map interface or just an interface itself and PicoContainer will provide a matching Map instance. A special feature is available due to the nature of the Map. The component adapter's key is used also as key in the injected Map.

Use Cases

While the usage of this collective types is straight forward, there are some special cases to consider. These special use cases are explained here.

Empty Collective Instances

Normally the dependency resolution for a collective type will fail, if no component of the specific component type is registered in the PicoContainer. With the constructors of ComponentParameter you have also the possibility to accept an empty collective type as a satisfying argument. Example code for an Array:

Example code for a Collection (Map is analogous):

Note that in both examples no other component was registered. This behavior is useful if you have a monitor with listeners, that can be registered by configuration. Even if no listener is configured, the monitor component is still instantiatable.

Precedence

PicoContainer will only generate a collective type on the fly, if no such type was registered before. So you can overwrite the dependency resolution (see example for a native Array):

Demonstrated with this unit test:

See same example code for a Collection (Map is again analogous):

But how can you circumvent such a situation and ensure that the collective type is generated even if one of the same type was registered? Make usage of the CollectionComponentParameter. Example code for an Array:

And here the example code for a Collection (Map is still analogous):

Scope

Any collective types will collect its components from the complete container hierarchy. See example code for Map types as a unit test:

All Cods have been found and put into the bowl. If two components are registered with the same key, the first found will be considered. This is even true, if it means that the component is not part of the collection. See example code again as unit test:

Dick the Shark took precedence over Dick the Cod.

Filter based on Key Type

A generated map automatically deliver the component adapter's key as key of the map entry. As for the generic types in Java 5.0 this key may be of a specific type. Just define it using the constructors of ComponentParameter. See the example code:

The unit test demonstrates that only named fishes are in the fish bowl:

But this key type selection does not only work with Map types, but also with Collection types and even with a native Array! See the unit test for the Array (although the ValueType parameter will be ignored for a native Array):

Individual Filter

Although filtering on component type or key type is useful, it might not be enough. Therefore you can add an additional and completely individual filter by overloading CollectionComponentParameter.evaluate(ComponentAdapter). See the example code to filter out the Cod named Tom:

An even more advanced filter mechanism is using the Constraint extension as provided in the picocontainer-gems.

Labels
  • None