> On Monday, February 24, 2003, at 12:26  PM, Bill Barnhill wrote:
> > FYI: my setup may be a little different: Sevak-Jetty
> > running out of Phoenix container, with Sevak hacked a
> > little so that it loads all webapps in /opt/webapps
> > (or whatever value of web-apps-dir is in config.xml
> > file). I then set my build.webapp (I think its the
> > right property?) dir to /opt/webapps/cocoon .
> >
> > Is anyone else travelling this road as well? If so I'd
> > like to hear about what you've found.
> 
> Yup :) I have my Phoenix application mounting a Sevak block 
> which loads 
> two web applications based on Cocoon, passing in a parent 
> ComponentManager so Cocoon can access other Phoenix blocks. I 
> recently 
> committed a patch to CocoonServlet which made 
> getParentComponentManager 
> a protected method so it can be overriden. All you have to do 
> is extend 
> CocoonServlet and make it Serviceable and use that as the parent for 
> Cocoon's container hierarchy.

I've done similar things to this. Only I've wrapped Cocoon so that I can declare it as 
an Avalon service. This way I can have several applications access the same Cocoon 
from the service manager. 

The service is really sketchy:

EmbeddedCocoon
{
    Cocoon getCocoon();
    
    /** unfortunately I need to know some cocoon specific context info
        in order to create the Environments to pass to Cocoon.
        I get with this accessor */
    Context getEmbeddedContext();
}

the implementation takes care of bootstrapping Cocoon handing it a customized Context, 
its Configuration etc. and monitoring its configuration for changes in order to reload 
when neccessary.
I am wondering if Cocoon shouldn't have one such Service itself. Now you should either 
have a command line or a servlet engine in order to start Cocoon.

I am not running Sevak/Phoenix for now, but I am considering this. Instead I'm loading 
ECM from a Catalina ServerListener. I let my webapps be created by custom Catalina 
Context loader so that ServiceManagers, LoggerManagers and InstrumentManagers are 
passed into the contexts as attributes.

It works ok but this approach does tie me to Tomcat.

Regards,
Unico

Reply via email to