cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [Propsal][C2/2.1] Cocoon2 component manager hierarchy
Date Mon, 27 Aug 2001 14:09:28 GMT
Leo Sutic wrote:
> 
> (I'm posting this both to Cocoon-dev and Avalon-dev, as the subject touches
> on both of them.)
> 
> The Problem: The sitemap components I write need access to components
> besides those available in the default Cocoon2 configuration.
> 
> Solution: Define some roles and point user-roles to them.
> 
> Why this isn't optimal: This means that every instance of Cocoon will
> re-load these roles as there is no system-wide component manager. Thus,
> assuming two cocoon webapps in the same Tomcat instance, if both instances
> have a threadsafe component there will be two instances of that component.
> (For example). Also, one can not easily add a component or reconfigure *all*
> C2 webapps from a single file.
> 
> What I'd like to have: A way to specify a parent component manager for
> Cocoon and generally for servlets. I'll discuss Cocoon here, as an example.
> I'm leaning towards letting Cocoon implement Composable, with the option of
> letting the ComponentManager parameter be the empty (non null) component
> manager.
> 
> The CocoonServlet would use this pattern to retrieve the parent component
> manager:
> 
> <init-param>
>         <name>parent-component-manager</name>
>         <value>MyComponentManager</value>
> </init-param>


Your problem is largly due to the fact that _EVERY_ WebApp is loaded in a
different classloader with no access to each other.  Anything else is a violation
of the Servlet spec and a security hazzard.

As long as everything is in one webapp, you will be able to share your component
manager instances.  You do need to pay special attention to forcing the load
order of your servlets within your webapps.  The one that creates the shared
instance must be loaded first.  Then you have to create the mechanism to share
the instance.

I really don't like static "root" ComponentManagers due to the security constraints
you have to enforce.  It is a logistical nightmare.  Any official solution has
to scale from no/low security to high security installations.


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.  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.

For non-J2EE installations, we can use Excalibur's naming package (Memory based JNDI
and RMI based JNDI providers).  You are still limited to one classloader with this solution,
but it would allow Cocoon to use one root instance.  (BTW, the RMI based solution will
work with any number of webapps, but you would need your own script to get it started
before the app server).  Neither of these provide authentication, so they are not
considered secure yet.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message