You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by do...@cocoon.apache.org on 2004/07/09 15:42:03 UTC
[Cocoon Wiki] Updated: ErrorHandling
Date: 2004-07-09T06:42:03
Editor: DerekLastname <dh...@csir.co.za>
Wiki: Cocoon Wiki
Page: ErrorHandling
URL: http://wiki.apache.org/cocoon/ErrorHandling
changed link from [pipelines] to [pipeline]
Change Log:
------------------------------------------------------------------------------
@@ -10,25 +10,25 @@
Each [:Pipeline] can define its own processing for error handling as follows:
-{{{<map:pipeline>
-
- <!-- ... matchers ... -->
-
- <map:handle-errors>
- <!-- error handling instructions -->
- </map:handle-errors>
-
-</map:pipeline>
+{{{<map:pipeline>
+
+ <!-- ... matchers ... -->
+
+ <map:handle-errors>
+ <!-- error handling instructions -->
+ </map:handle-errors>
+
+</map:pipeline>
}}}
The error handling instructions can be any of the usual Sitemap [:Components] ''except'' a [:Generator]. This is because Cocoon has a special [http://xml.apache.org/cocoon/userdocs/generators/error-generator.html ErrorGenerator] which is used to feed details of an exception, as SAX events, into the error handling pipeline. The !ErrorGenerator documentation includes a description of the XML that is created by the !ErrorGenerator.
This means that you can create a user-friendly error page by adding a [:Transformer] and [:Serializer] to the {{{<map:handle-errors/>}}} element. The default Cocoon Sitemap does this as follows:
-{{{<map:handle-errors>
- <map:transform src="stylesheets/system/error2html.xsl"/>
- <map:serialize status-code="500"/>
-</map:handle-errors>
+{{{<map:handle-errors>
+ <map:transform src="stylesheets/system/error2html.xsl"/>
+ <map:serialize status-code="500"/>
+</map:handle-errors>
}}}
Note that you can look at the {{{error2html.xsl}}} stylesheet as an example of how to process error documents using XSLT, and that the (default) HTML serializer is being instructed to return an HTTP status code of 500 (Server Error) to the users browser.
@@ -37,21 +37,21 @@
Looking through the default Cocoon Sitemap you can see that it's mostly a single large [:Pipeline] with a single error handler. So it seems to make sense to follow this pattern if you have a generic way of handling errors.
-However if you want to have specific error reports from particular kinds of processing, you should create separate [:Pipelines] which can have their own error handling instructions. E.g:
+However if you want to have specific error reports from particular kinds of processing, you should create separate [:Pipeline]s which can have their own error handling instructions. E.g:
-{{{<map:pipeline>
- <!-- XSLT transform pipe -->
- <map:handle-errors>
- <!-- handle errors for this pipeline
- </map:handle-errors>
-</map:pipeline>
-
-<map:pipeline>
- <!-- Reading transform pipe -->
- <map:handle-errors>
- <!-- custom handler for second pipeline
- </map:handle-errors>
-</map:pipeline>
+{{{<map:pipeline>
+ <!-- XSLT transform pipe -->
+ <map:handle-errors>
+ <!-- handle errors for this pipeline
+ </map:handle-errors>
+</map:pipeline>
+
+<map:pipeline>
+ <!-- Reading transform pipe -->
+ <map:handle-errors>
+ <!-- custom handler for second pipeline
+ </map:handle-errors>
+</map:pipeline>
}}}
----
@@ -64,11 +64,11 @@
The following code goes after the {{{<map:match />}}}; section(s) in your pipeline(s). (I found the example in the sitemap in the "sub" directory under the default Cocoon installation.)
-{{{
-<map:handle-errors type="500">
- <map:transform src="stylesheets/error2html.xsl"/>
- <map:serialize/>
-</map:handle-errors>
+{{{
+<map:handle-errors type="500">
+ <map:transform src="stylesheets/error2html.xsl"/>
+ <map:serialize/>
+</map:handle-errors>
}}}
This method allows you to specify multiple custom error pages for multiple pipelines based on the error type.
@@ -90,20 +90,20 @@
The sitemap fragment below shows the use of the two different types in one pipeline
-{{{
- <map:pipeline>
- <map:match pattern="test/**">
- <map:mount check-reload="yes" src="oreilly/sitemap.xmap" uri-prefix="test"/>
- </map:match>
- <map:handle-errors type="500">
- <map:transform src="stylesheets/system/error-2-html.xsl"/>
- <map:serialize/>
- </map:handle-errors>
- <map:handle-errors type="404">
- <map:transform src="stylesheets/system/error404-2-html.xsl"/>
- <map:serialize/>
- </map:handle-errors>
- </map:pipeline>
+{{{
+ <map:pipeline>
+ <map:match pattern="test/**">
+ <map:mount check-reload="yes" src="oreilly/sitemap.xmap" uri-prefix="test"/>
+ </map:match>
+ <map:handle-errors type="500">
+ <map:transform src="stylesheets/system/error-2-html.xsl"/>
+ <map:serialize/>
+ </map:handle-errors>
+ <map:handle-errors type="404">
+ <map:transform src="stylesheets/system/error404-2-html.xsl"/>
+ <map:serialize/>
+ </map:handle-errors>
+ </map:pipeline>
}}}
Remember that when a {{{<map:handle-errors>}}} is not found for the type of exception you want to process in the current pipeline, cocoon will try to find one in the parent sitemap (if using sub-sitemap). If no such handler is found, the exception will be handeld by the Cocoon Servlet !
@@ -121,25 +121,25 @@
if you want to display the original error message in your own xsp ...
-{{{
-<xsp:logic>
-// dump error to stderr so we can fix it. /te
-
-System.err.println("---UNCAUGHT EXCEPTION IN SITEMAP");
-
-org.apache.cocoon.components.notification.Notifying notification =
-(org.apache.cocoon.components.notification.Notifying)objectModel.get(org.apache.cocoon.Constants.NOTIFYING_OBJECT);
-
-System.err.println(notification.getDescription());
-java.util.Map m = notification.getExtraDescriptions();
-if (m!=null)
-{
- Object t = m.get("stacktrace");
- if (t!=null)
- System.err.println(t);
-}
-System.err.println("---");
-</xsp:logic>
+{{{
+<xsp:logic>
+// dump error to stderr so we can fix it. /te
+
+System.err.println("---UNCAUGHT EXCEPTION IN SITEMAP");
+
+org.apache.cocoon.components.notification.Notifying notification =
+(org.apache.cocoon.components.notification.Notifying)objectModel.get(org.apache.cocoon.Constants.NOTIFYING_OBJECT);
+
+System.err.println(notification.getDescription());
+java.util.Map m = notification.getExtraDescriptions();
+if (m!=null)
+{
+ Object t = m.get("stacktrace");
+ if (t!=null)
+ System.err.println(t);
+}
+System.err.println("---");
+</xsp:logic>
}}}
(works for cocoon 2.1rc1)
@@ -151,8 +151,8 @@
The notifying generator and the XSP above don't show the original error message if it comes from a {{{<xsl:message>}}} in a XSL stylesheet.
This always gives the message
-{{{
-org.apache.cocoon.ProcessingException: Failed to execute pipeline.: java.lang.RuntimeException: Stylesheet directed termination
+{{{
+org.apache.cocoon.ProcessingException: Failed to execute pipeline.: java.lang.RuntimeException: Stylesheet directed termination
}}}
Does anyone know a way to get the original message?