cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <>
Subject Re: RT: Further integration with Avalon?
Date Tue, 25 Feb 2003 11:41:57 GMT
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.

> Eventually I would like to be able to :
> 1. Create a .sar file that packages one or more Cocoon
> blocks
> 2. Deploy that .sar file by dropping it into
> $PHOENIX/apps
> 3. On the .sar's deployment have it publish a
> CocoonBlockService
> 4. Have A Cocoon.sar (based on Sevak) look for on
> startup, and listen for during the lifecycle,
> instances of CocoonBlockService and integrate the
> represented block within Cocoon.
> 5. Add a 'sar' target to builds the sar file in the
> 'build.sar'  location (set in
> and possibly defaulting to $PHOENIX/apps if $PHOENIX
> is not null).

The kicker here is that there is (currently) no way to have inter-SAR 
communication in phoenix. Each SAR is its own isolated application. 
Sevak's current design is at the block level, rather than at the SAR 
level. What you could do is create a single SAR with a Sevak-hosted 
Cocoon as well as other block's and have those other blocks be 
available to Cocoon (basically the design I outlined above).

With the new "auto-assembly" patches for Phoenix, your step 4 could be 
accomplished by declaring an Array dependency on a CocoonBlockService, 
and then the Sevak-hosting block would automatically pick up all 
CocoonBlockServices w/o having to do a listener.

> I'd love to hear thoughts from people more experienced
> with Avalon and/or Cocoon (just about everybody right
> now) on whether this is
> a) Has been done before

You're on the cutting edge of integration ;)

> c) a 'good thing' and suggestions on how to go about
> it

Outlined above :) Feedback welcome!

View raw message