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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
