cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: [C2] handle-errors with content aggregation: not for ResourceNotFound???
Date Mon, 23 Jul 2001 13:38:21 GMT
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" <balld@webslingerZ.com>
> To: <cocoon-dev@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


Mime
View raw message