When using Apache Cocoon it is sometimes neccessary to obtain
components from other sources than the user.roles
file,
or preferable to have a common component manager for several web applications.
The pattern chosen for Cocoon is the dynamic loading of a component manager class.
The initialization parameter parent-component-manager in web.xml specifies a class
that will be loaded, instantiated and used as a parent component manager for
Cocoon's component manager.
The recommended procedure is for the class, when it is initialized, to create a
delegate in the form of an ExcaliburComponentManager
, configure it
by looking up a Configuration
object via JNDI, and delegate any requests to it.
In order to provide a way to pass parameters to the parent component manager class
(the class specified in parent-component-manager), Cocoon will instantiate the class
via the constructor that takes a single String
argument, passing
anything to the right of the first '/'
in the parameter value to the
constructor. Subsequently Cocoon examines whether the class implements
org.apache.avalon.framework.logger.Loggable
and/or
org.apache.avalon.framework.activity.Initializable
and calls
setLogger
and/or initialize
, as appropriate.
The instance is then used as a parent component manager.
Since that didn't make much sense in itself, let's look at the sample.
The goal is to define a component that can give us the time of day and
let it be managed by a parent component manager.
So, first we need to put a Configuration object into JNDI, and then
grab that object, use it to configure an ExcaliburComponentManager,
and pass on any requests to that manager.
 |  |  |
 | Step 1: Creating a configuration object |  |
 |  |  |
 |  |  |
 | Step 3: Tell Cocoon to use the component manager |  |
 |  |  |
 |  |  |
 | Step 4: Use the component |  |
 |  |  |
And that concludes the tour. A parent component manager was initialized with a configuration
obtained via JNDI and its components used by a Cocoon generator.