Vadim Gritsenko wrote:
<map:pipeline internal-error-handling="true">
Or even better, let's put this information on the handle-error statement itself, because it's really where it belongs:
Only problem I see with it is that it opens up a scenario:
<map:pipeline>
...
<map:handle-errors when="internal">
...
</map:handle-errors>
<map:handle-errors when="external">
...
</map:handle-errors>
</map:pipeline>And I'm not sure we want to go there. Hence, attribute on the pipeline itself is better, IMHO. It indicates that this is a feature of the pipeline (similar to internal-only="true").
OTOH, using handle-errors attribute allows for:
<map:pipelines>
<map:pipeline>
...
</map:pipeline>
<map:handle-errors when="always">
...
</map:handle-errors>
</map:pipeline>Which otherwise would require attribute on map:pipelines, if that feature is needed at all.
<map:handle-errors when="external|internal|always">
Isn't <map:handle-errors when="internal"> FS? What would be the scenario for having error handler for internal but not external requests?
When attribute is missing or set to false, error handling behaviour is as it is currently. Limitation of current implementation of the feature is that only one, the inner most one error handler will be used for error handling. Implementation can be extended to support hierarchical error handlers, but I followed KISS and YAGNI approaches.
Internal requests have the problem that pipeline execution occurs out of the control of the sitemap engine. Does the above restriction apply to pipeline build-time or pipeline execution-time?
Yes, good catch. I implemented single error handler for pipeline processing time. Pipeline assembly stage can use hierarchical handlers.
Vadim
Because it's getting pretty close to the code freeze, I'd like to run this through the vote. So, please vote here:
[X] Let's include this feature into 2.1.7 release!
With a better naming and with a clear description of the current limitations (and the fact that they may be removed in the future)
[ ] No, it can wait...
And here:
[ ] Single error handler is just what we need. [ ] No, it must support hierarchical error handling.
And here is place for suggestions:
[X] I don't like attribute abive and propose following configuration attribute and values: ...
See above !
[ ] I suggest ...
Sylvain
