Components represent "Services doing things" in the Shaman system. The idea is to define contracts (through the use of Java interfaces), and assemble the components during application initialization, from configuration files or other contextual information.

Cocoon 2 relies heavily on Avalon Components. Being an Avalon Component is necessary and sufficient for extending Cocoon. See Cocoon documentation and samples for more details.

Some Components may expose their interface to remote RMI clients. At the same time, they should support running without being RMI-registered. This leads to three possible contexts :

• Implementation is ran as a regular in-process Singleton, no RMI stuff involved.
• Implementation is ran as a regular in-process Singleton, but is exposed at the same time as a RMI server object.
• The server object is a RMI proxy.

RMI documentation states it is possible to expose an RMI server object without deriving from java.rmi.server.UnicastRemoteObject. This requires a few tricks (left undocumented by Sun Microsystems) for obtaining a correct behavior under all circumstances. See fr.paris5.shaman.insight.component.AbstractExposedService for details.

Apache Jakarta-Avalon is the framework of choice for managing our components. It was an obvious choice for Cocoon integration, but we discovered quickly that it was a very powerful mean of structuring our application.

Here are some interesting features provided by this framework :

The Avalon framework defines the lifecycle of Components. No more tricky questions about initialization sequence, just follow the contracts.

The Components are registered in a Component Manager, which is able to deliver a Component instance for a given role (defined by a String, which is, by convention, the full-qualified name of the Java interface). When you need a Component instance to perform something, just ask your Component Manager.

The Avalon framework provides facilities for instantiating and configuring Components from a configuration file.

Component Managers can contain other Components. (Most of time) this containment hierachy is defined in the XML configuration file. The pattern for accessing objects in the hierarchy is "bottom-up" style, in other words, no recursive exploration of the containment tree should be done.

Components can be associated to a Logger declared in the configuration file. Loggers can have their own hierachy (by default, a loggable Component will inherit of it's parent's logger). This makes logging extremely powerful, configurable, and easy to setup.

All details can be found on :

• Apache Jakarta-Avalon-Framework
• Apache Jakarta-Avalon-Excalibur
• Apache Jakarta-Avalon-LogKit