The need of Components
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.Interoperability
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.Context-sensitivity
Some Components may expose their interface to remote RMI clients.
At the same time, they should support running without being
This leads to three possible contexts :
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 :Lifecycle
The Avalon framework defines the lifecycle of Components. No more tricky questions about initialization sequence, just follow the contracts.Role-based access
The Components are registered in a Component Manager, which is able
to deliver a Component instance for a given role
(defined by a
The Avalon framework provides facilities for instantiating and configuring Components from a configuration file.Hierarchical containment
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.Logging
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.Apache documentation
All details can be found on :