A component lives within something called a container. The contract between a container and a contained component is simple: the container is required to take a component through what is called its lifecycle.
The Avalon project provides an application that functions as a container for componentized applications called Phoenix. This is not exclusive, components adhering to lifecycle interfaces, can be mounted in custom containers. Cocoon and others mounts their own containers for components and invoke relevant methods from the lifecycle interfaces. See Containers.
The lifecyle methods from the Avalon Framework sub-project are designed to be used by just about any component hosted by any container. Of course, the API in question may well require additional interfaces for strongly typed functionality, but these interfaces should negate the need for any duplication of effort.
The lifecycle of a component specifies the methods that can be called on it,
and the order in which this may happen. Some methods can be called only once
in a specific phase
of a component's lifecycle, others may
be called multiple times. These methods are called the lifecycle methods.
It is up to each container to indicate which lifecycle methods it will honor. This should be clearly documented together with the description of the container. A sister project to Phoenix supports all of the lifecycle methods defined in the Avalon Framework API.
A component exposes its lifecycle methods by implementing the lifecycle interfaces. Each of these defines one or more methods that represent a specific phase in a component's lifecycle. The defined interfaces are:
Note:java.lang.Runnable has also been in use as a lifecycle interface. This is not recommended and is not supported by Avalon. Instead, the run() method is the responsibility of the component itself. If you wish to use it, call it from within start() or another method.
The order in which the various lifecycle methods are called is very specific. While none are required (it is possible to have a component implementing none of the lifecycle methods, although the use of that would be limited), some can only be used when others are as well. This is best explained using a few examples.