You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jan Uyttenhove <ja...@pandora.be> on 2001/07/14 00:39:58 UTC
Re: [C2] handle-errors with content aggregation: not for ResourceNotFound???
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" <ba...@webslingerZ.com>
To: <co...@xml.apache.org>
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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2] handle-errors with content aggregation: not for ResourceNotFound???
Posted by Carsten Ziegeler <cz...@sundn.de>.
First: sorry for this late response.
> Jan Uyttenhove wrote:
>
> 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?
The reason is: It's the way it is implemented. Not less, not more.
I understand your issue, but I am not sure what's the better solution.
I would suggest that you start a vote on this list for this special
topic. If you get enough "+1", it will be changed.
I am +0 on this.
>
> 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?
The motivation behind this is that Cocoon acts like a usual web server,
which means if a page can not be found (= no match), you get the http
status resource not found.
> I want my handle-errors to deal with all errors, including the
> ResourceNotFound. Now I get the (hardcoded) cocoon-blue formatted
> errorpage,
Yes, this is the really bad part. But here comes the good news:
This is fixed in the beta 2, you now get only the http status code 404
(= resource not found).
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
> 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/langu
> age/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" <ba...@webslingerZ.com>
> To: <co...@xml.apache.org>
> 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: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org