I finally implemented the very old todo about allowing generators in <map:handle-errors> (see [1]). This means that you are no more forced to have an initial XML document representing the error, but you can instead build a regular pipeline with whatever generator you want.
I also have added a new ExceptionSelector that allows to easily drive the construction of the error pipeline depending on the actual error that occured (see examples below).
However, allowing a generator in <map:handle-errors> is incompatible with the current syntax. So, the choice between with/without implicit generator is driven by the presence of the "type" attribute on <map:handle-errors> :
- if there is a "type" attribute (which can have the values 404 or 500), the "old" implicit generator behaviour is used,
- if there is no "type" attribute, the new behaviour is used, and there must be an explicit generator.
This second item may break existing sitemaps. The solution is to simply add a type="500" attribute to obtain the "old" behaviour (the 'type' attribute, an old-time hack, is now deprecated).
The sitemap engine takes care of issuing meaningful error messages if the error-handling pipeline is not correctly build, to ensure users won't get stuck with strange messages caused by this compatibility problem. The message is as follows :
"Incomplete pipeline : 'handle-error' without a 'type' must include a generator, at sitemap.xmap:134:67
Either add a generator (preferred) or a type='500' attribute (deprecated) on 'handle-errors'"
Here's how error-handling in the main sitemap now looks like :
<map:handle-errors>
<map:select type="exception">
<map:when test="not-found">
<map:generate src="not-found.xml"/>
<map:transform src="welcome.xslt"/>
</map:when>
<map:otherwise>
<map:generate type="notifying"/>
<map:transform src="stylesheets/system/error2html.xslt">
<map:parameter name="contextPath" value="{request:contextPath}"/>
</map:transform>
</map:otherwise>
</map:select>
<map:serialize/>
<map:handle-errors>This means that when we have a "not-found" type of error, we display a static document, while other errors are handled the usual way, now using explicitely the "notifying" generator to start the pipeline.
The ExceptionSelector is configured as follows in the main sitemap :
<map:selector logger="sitemap.selector.exception"
name="exception" src="org.apache.cocoon.selection.ExceptionSelector">
<exception name="not-found" class="org.apache.cocoon.ResourceNotFoundException"/>
<!-- The statement below tells the selector to unroll as much exceptions as possible -->
<exception class="java.lang.Throwable" unroll="true"/>
</map:selector>
This allows to :
- associate symbolic names to one (or more) exception class names
- define which exceptions should be "unrolled", meaning their cascaded exception, if any, is taken into account to find the symbolic name. This allows match the actual exceptions that caused the error even if they were rethrown embedded in a higher-level exception.
This configuration is processed top-down up to the first matching exception, meaning that, just as in a Java "catch" clause, most specific classes must come first (the selector checks this).
Enjoy, Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102637618202439&w=2
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
