cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Forwarding of internal pipeline calls
Date Mon, 08 Mar 2004 14:44:31 GMT
Carsten Ziegeler wrote:

>While using internal cocoon redirects, I found out that there are
>potential problems with error handling (it might be that we have
>discusses this already...).
>Now, if you do a:
><map:redirect-to uri="cocoon://something"/>
>than this is an internal pipeline call (and not a new http request).
>This has of course some advantages (e.g. performance etc), but
>has imho the drawback that in this case, the error handling
>of the calling pipeline is *always* used. This means if an error
>occurs while processing the "something" pipeline, the error
>handler of the pipeline containing the redirect-to is invoked.
>Now, in general this might be a good solution for internal pipeline
>calls when they are used in a map:generate etc., but it's imho
>a little unusal for a redirect.
>We had recently the discussion on this list, if we need a general
>solution to specify which error handler is used for internal pipeline
>calls. I discussed this a little bit with Vadim on IRC during our
>first friday and he suggest to specify this not on the caller but
>on the called pipeline. So the map:pipeline containing the
>"something" pipeline specifies what to do. Regardless if this is
>the better choice than specifying it in the uri ("cocoon:...."),
>it's technically nearly impossible. When the internal pipeline
>is called, everything happens outside the treehandler and there is
>no real chance to get the error handler etc. (Of course we could
>change something here and there and then it will work.)

Sorry, what is "technically nearly impossible"??

>So, I just tried the other way:
><map:redirect-to uri="cocoon://something?cocoon:forward=true"/>
>The current implementation I have can only be used for redirects,
>although it's fairly simple to extend it to be used in
>map:generate etc. as well.
>WDYT? Is this of general interest?

This question comes regularly on the table. Maybe it's time to give it 
an answer now :-)

The current state is that <map:handle-errors> is considered only for 
requests coming directly from the outside world, and not for internal 
requests (i.e. "cocoon:").

Firstly, this behaviour is IMO bad for forwards (redirects to 
"cocoon:"): forwarding should fully delegate the request, including 
error handling. Fixing this can be accomplished easily by overriding 
isInternal() in TreeProcessor.ForwardEnvironmentWrapper: instead of 
always returning false, we can delegate the call to the wrapped 
environment (will return true on http and cli environments).

Secondly, we have to define means for handle-errors to be used on 
internal requests (i.e. SitemapSource). And in that case, as you 
outlined, this can be determined by the caller (the place where the 
"cocoon:" occurs) or in the callee (the called pipeline).

- by the caller, I don't see any other way than using an additional 
parameter as you proposed above. But instead of "cocoon:forward", naming 
it "cocoon:handle-errors" seems more adequate.

- by the callee, this can be done using an additional attribute on the 
error-handler. What comes to mind is <map:handle-errors 

Policy defined by the caller should have precedence over the one defined 
in the pipeline.

How does it sound?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message