cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Generators now allowed in <map:handle-errors>
Date Tue, 01 Apr 2003 21:35:02 GMT
Hi team,

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 }



Mime
View raw message