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 requests="external|internal|all">
Policy defined by the caller should have precedence over the one defined in the pipeline.
How does it sound?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
