You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2001/08/27 13:01:48 UTC
[Propsal][C2/2.1] Cocoon2 component manager hierarchy
(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>
.
.
.
String parentComponentManagerClass =
conf.getInitParameter("parent-component-manager");
ComponentManager parentComponentManager = null;
if (parentComponentManagerClass != null)
parentComponentManager = (ComponentManager) ClassUtils.newInstance
(parentComponentManagerClass);
} else {
parentComponentManager = new ExcaliburComponentManager ();
}
if (parentComponentManager instanceof Initializable) {
parentComponentManager.initialize ();
}
.
.
.
this.cocoon.compose (parentComponentManager);
.
.
.
Now for the Avalon parts: This would be even clearer if one could implement
the Factory pattern here by having a parent component manager Factory
instead of a parent component manager:
<init-param>
<name>parent-component-manager-factory</name>
<value>MyComponentManagerFactory</value>
</init-param>
.
.
.
String parentComponentManagerFactoryClass =
conf.getInitParameter("parent-component-manager-factory");
ComponentManager parentComponentManager = null;
if (parentComponentManagerFactoryClass != null)
parentComponentManagerFactory = (ComponentManagerFactory)
ClassUtils.newInstance (parentComponentManagerFactoryClass);
}
.
.
.
if (parentComponentManagerFactory != null) {
this.cocoon.compose (parentComponentManagerFactory.newComponentManager ());
} else {
ExcaliburComponentManager empty = new ExcaliburComponentManager ();
empty.initialize ();
this.cocoon.compose (empty);
}
SUMMARY:
What is needed:
- (Avalon) A ComponentManagerFactory interface defined like this:
public interface ComponentManagerFactory {
public ComponentManager newComponentManager ();
}
- (Cocoon2) Let Cocoon implement composable. Let it use the CM passed to
compose as a parent component manager.
- (Cocoon2) Let Cocoon load a ComponentManagerFactory based on the
parent-component-manager-factory parameter in web.xml.
BENEFITS:
- (Avalon/Cocoon2) A standardized way of passing parent component managers
to servlets. Thus making configuration easier.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Propsal][C2/2.1] Cocoon2 component manager hierarchy
Posted by Peter Donald <do...@apache.org>.
On Tue, 28 Aug 2001 00:09, Berin Loritsch wrote:
> 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.
thats what I thought ;)
> 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.
Another solution would be to put it in application scope from jsp ... err
forget what that is in real terms. I think application scope roughly
translates into something like
getServletContext().
setAttribute( "my-global-root-CM-that-is-unsafe", myComponentManager );
This will be exposed to all servlets in same webapp.
--
Cheers,
Pete
*------------------------------------------------------*
| "Computers are useless. They can only give you |
| answers." - Pablo Picasso |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Propsal][C2/2.1] Cocoon2 component manager hierarchy
Posted by Peter Donald <do...@apache.org>.
On Tue, 28 Aug 2001 00:09, Berin Loritsch wrote:
> 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.
thats what I thought ;)
> 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.
Another solution would be to put it in application scope from jsp ... err
forget what that is in real terms. I think application scope roughly
translates into something like
getServletContext().
setAttribute( "my-global-root-CM-that-is-unsafe", myComponentManager );
This will be exposed to all servlets in same webapp.
--
Cheers,
Pete
*------------------------------------------------------*
| "Computers are useless. They can only give you |
| answers." - Pablo Picasso |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [Proposal][C2/2.1] Cocoon2 component manager hierarchy
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Berin,
thank you very much for your insights.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> 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
order.
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:
<init-param>
<name>root-component-manager</name>
<value>org.apache.my.CMWrapper:org/apache/my/ComponentManager</value>
</init-param>
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.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Proposal][C2/2.1] Cocoon2 component manager hierarchy
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Berin,
thank you very much for your insights.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> 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
order.
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:
<init-param>
<name>root-component-manager</name>
<value>org.apache.my.CMWrapper:org/apache/my/ComponentManager</value>
</init-param>
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.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Propsal][C2/2.1] Cocoon2 component manager hierarchy
Posted by Berin Loritsch <bl...@apache.org>.
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
Re: [Propsal][C2/2.1] Cocoon2 component manager hierarchy
Posted by Berin Loritsch <bl...@apache.org>.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org