cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <>
Subject RE: [Proposal][C2/2.1] Cocoon2 component manager hierarchy
Date Mon, 27 Aug 2001 15:31:10 GMT

thank you very much for your insights.

> -----Original Message-----
> From: Berin Loritsch []
> Sent: den 27 augusti 2001 16:09
> To: Avalon Development
> Cc: Cocoon Developer's List
> Subject: Re: [Propsal][C2/2.1] Cocoon2 component manager hierarchy


> I really don't like static "root" ComponentManagers due to the
> security constraints
> you have to enforce.

I agree completely - this is precisely the situation I want to avoid.

> One mechanism that is available to users of J2EE solutions is
> JNDI.  If you can have your enterprise application create your
> root component manager, you can access it from JNDI.

Yes. This would solve the problem.

> This will even allow you to span webapps--but it is done in a safe
> and well tested secure mechanism.  If you would be open to J2EE, then I
would be
> open to allowing Cocoon to use JNDI to get the root ComponentManager.

I am open for J2EE/JNDI. Very open, in fact.

Now, in a clustered environment, what I would like to do in order to avoid
having to force the load order is to have one of my EJB servers start the
root CM as a service and bind it to a JNDI name. As this is done non-lazily
(all services are started before the EJB server is considered "up") the
Tomcat instances and Cocoons in the cluster can then load servlets in any

The ExcaliburComponentManager can not work as a remote object, as the
component references get all messed up if the components travel across the
network, and there is no requirement for components to be remote objects.

So the CM would have to travel across the wire when it is looked up.

However, should one want to run the CM remotely (for whatever reason), the
connection must be dropped periodically as the RMI libraries (in my
experience) leak memory. This means we need a wrapper around the remote CM.

Thus I believe that the factory pattern is applicable here:


Where the part before the ':' is the factory class, and the part after the
first ':' is parameters to the factory. This way one can use JNDI or
whatever method is applicable, and avoid the load order problem.


To unsubscribe, e-mail:
For additional commands, email:

View raw message