Guys,
I followed the discussion, and I want to add two things about handle-errors
and content aggregation, both causing a somewhat surprising behaviour of
cocoon when an error occurs:
1. I wondered why the handle-errors finishes the content aggregation when an
error occurs. When I aggregate 4 parts, and an error occurs in the third
part, I'd like the error message (handled and formatted by the
handle-errors) to be aggregated as the third part, and still get the fourth
part completing my aggregation. This is not the case right now. Inside the
generate methode of the ContentAggregator, an exception finishes the
execution of a 'for' loop (generating all the parts): in the catch block, it
rethrows the exception and the loop ends.
If this wasn't the case, I could format my error inside my aggregation, and
create at least a decent page. But now, the output of the handle-errors is
simply added at the end, so after the (incomplete) aggregation.
Why can't handle-errors simply influence the part in which the error occurs
(not all remaining parts, not the whole content aggregation)? If so, I can
build an 'aggregated' error page, I can continu execution after an error
occurs, which would make life much easier for me, as long as I can 't
redirect to a static page.. :-)
Is there a reason for this behaviour?
2. I also found out that a ResourceNotFoundException is thrown, if there's
no match for my request in the sitemap. Allright... I actually managed to
create an infinite loop in the sitemap, when creating a match pattern="**/"
including a redirect... :-)... whatever.
But if there's no match in my sitemap, and an exception is thrown, I thought
the handle-errors would take over and process this error, so I wouldn't have
to use this final match pattern="**/". Nope. The ResourceNotFoundException
is caught in the process method of the generated sitemap.java, but nothing
is done with the exception. The handle-errors is called for all exceptions,
except for ResourceNotFound and ConnectionReset.
Again, what's the motivation?
I want my handle-errors to deal with all errors, including the
ResourceNotFound. Now I get the (hardcoded) cocoon-blue formatted errorpage,
and our customers won't like that. So here's a patch, to let handle-errors
deal with ResourceNotFound, unless there's a good reason not to do this of
course.. :-)
Your opinions/motivations?
Kind regards,
Jan
Jan Uyttenhove
Software Engineer
The E-corporation
Index: sitemap.xsl
===================================================================
RCS file:
/home/cvspublic/xml-cocoon2/src/org/apache/cocoon/components/language/markup
/sitemap/java/sitemap.xsl,v
retrieving revision 1.11
diff -u -r1.11 sitemap.xsl
--- sitemap.xsl 2001/06/05 21:36:23 1.11
+++ sitemap.xsl 2001/07/13 16:20:21
@@ -411,6 +411,7 @@
Map objectModel = environment.getObjectModel();
String cocoon_view = environment.getView();
String cocoon_action = environment.getAction();
+ boolean hasMatch = false;
<!-- process the pipelines -->
<!-- for each pipeline element generate a try/catch block -->
@@ -421,11 +422,9 @@
</xsl:if>
try {
<xsl:apply-templates select="./*"/>
+ if (!hasMatch) { throw new ResourceNotFoundException("404
Resource Not Found"); }
} catch (ConnectionResetException cre) {
getLogger().debug("Connection reset by peer");
- } catch (ResourceNotFoundException rse) {
- getLogger().warn("404 Resource Not Found", rse);
- throw rse;
} catch (Exception e) {
getLogger().warn("Error, try to process the error page", e);
<xsl:choose>
@@ -559,6 +558,7 @@
<!-- this is the actual code produced -->
if ((map = <xsl:value-of select="$matcher-name"/>) != null) {
+ hasMatch = true;
getLogger().debug("Matched <xsl:value-of select="$matcher-type"/>
<xsl:value-of select="$matcher-name2"/>");
listOfMaps.add (map);
<xsl:apply-templates/>
----- Original Message -----
From: "Donald Ball" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 13, 2001 6:44 PM
Subject: Re: AW: [C2] handle-errors with content aggregation
> On Fri, 13 Jul 2001, Carsten Ziegeler wrote:
>
> > I do not totally disagree, but I don't like the configuration part of
it.
> > When you design your site/create the sitemap you don't want to think
> > about how the pipelines should be handled: if the output stream
> > should be directly written or "cached" and then written.
>
> if not the sitemap editor, then who?? who else knows what the urlspace of
> the site looks like, and where response speed is more important than the
> possibility of catching errors properly? i think this is totally the
> domain of the sitemap editor. and sitemap editors who _don't_ care about
> or understand this can simply ignore the feature and let c2 behave as it
> does now, right?
>
> - donald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
