You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Uyttenhove Jan <Ja...@the-ecorp.com> on 2001/07/11 16:05:57 UTC
[C2] handle-errors with content aggregation
Hi all,
I'm currently working on a site that frequently uses content aggregation.
But when an error occurs, I should be able to show a nice error page, not
the standard cocoon error page. So now I'm trying to use the handle-errors
for this purpose, but I have some problems when an error occurs in a part of
a aggregated page.
An example:
<map:aggregate element="page">
<map:part src="header.xml" element="header"/>
<map:part src="left.xml" element="left"/>
<map:part src="middle.xml" element="middle"/>
<map:part src="footer" element="footer"/>
</map:aggregate>
and
<map:handle-errors>
<map:transform src="stylesheets/system/error2html.xsl"/>
<map:serialize status-code="500"/>
</map:handle-errors>
When an error occurs while generating the part middle.xml, I get a page
containing header, left and the (transformed) cocoon error, but no footer.
This is not exactly what I want, so I tried a redirect to a static error
page inside the handle-errors block:
<map:handle-errors>
<map:redirect-to uri="errorpage"/>
</map:handle-errors>
This doesn't work either, I get:
(...)
DEBUG 64521 [cocoon ] (Thread-6): Sitemap: session='false',
redirecting to 'errorpage'
DEBUG 64521 [cocoon ] (Thread-6): Sending redirect to 'errorpage'
ERROR 64521 [cocoon ] (Thread-6): error notifier barfs
java.lang.IllegalStateException: Response has already been committed
at
org.apache.tomcat.facade.HttpServletResponseFacade.sendError(HttpServletResp
onseFacade.java:204)
at
org.apache.tomcat.facade.HttpServletResponseFacade.sendRedirect(HttpServletR
esponseFacade.java:230)
at
org.apache.cocoon.environment.http.HttpResponse.sendRedirect(HttpResponse.ja
va:84)
at
org.apache.cocoon.environment.http.HttpEnvironment.redirect(HttpEnvironment.
java:106)
at
org.apache.cocoon.www.sitemap_xmap.error_process_1(sitemap_xmap.java:5035)
at org.apache.cocoon.www.sitemap_xmap.process(sitemap_xmap.java:5003)
at org.apache.cocoon.www.sitemap_xmap.process(sitemap_xmap.java:1245)
at org.apache.cocoon.sitemap.Handler.process(Handler.java:175)
at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:94)
at org.apache.cocoon.Cocoon.process(Cocoon.java:293)
at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:471)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
(...)
which makes sense, as my header part and left part of the aggregation have
already been committed, right?
So I can't redirect here, because I'm handling errors in one part of my
aggregation, and the first two parts have already been committed.
But if I handle errors of a part of the aggregation, and of the aggregation
itself, then why isn't the last part of the aggregation displayed?
And what can I do to simple show an error page, without any remaining
aggregation parts?
Any suggestions?
Thanx,
Jan
___________________________________________________
Jan Uyttenhove
- Software Engineer -
The E-corporation
Roderveldlaan 3 bus 1
B-2600 Antwerpen
Guldensporenpark 10 (Axxes 51-003)
B-9820 Merelbeke-Gent
T:+32 [0]9 272.22.00
F:+32 [0]9 272.22.11
______________________________________
- Good company for the road ahead - www.the-ecorp.com
<http://www.the-ecorp.com/>
Re: AW: [C2] handle-errors with content aggregation
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler a écrit :
>
> As this is a small and simple patch which will hopefully avoid
> a lot of questions by the users about the problem, I think
> we should include it in the beta2.
>
> Carsten
>
OK. Done also in 2.0 branch.
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
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
Posted by Carsten Ziegeler <cz...@sundn.de>.
As this is a small and simple patch which will hopefully avoid
a lot of questions by the users about the problem, I think
we should include it in the beta2.
Carsten
> -----Ursprüngliche Nachricht-----
> Von: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> Gesendet: Mittwoch, 18. Juli 2001 14:26
> An: cocoon-dev@xml.apache.org
> Betreff: Re: AW: [C2] handle-errors with content aggregation
>
>
>
>
> giacomo a écrit :
> <snip/>
> > >
> > > [Sorry for this late answer, it's hard to follow the list these days]
> > >
> > > The servlet API provides some methods to check if the servlet engine's
> > > output buffer has been flushed to the client browser
> > > (ServletResponse.isCommited) and, if no, to reset this buffer
> > > (ServletResponse.reset).
> > >
> > > Before calling the error-handler, the sitemap could reset the response
> > > if possible. This would allow for a higher probability of having clean
> > > error pages displayed to the user.
> > >
> > > Does it make sense ?
> >
> > It make sense to me. So, patch the error handler :)
> >
> > Giacomo
> >
>
> Done on the main branch.
>
> Carsten, should I commit it also on 2.0 now, or after beta 2 ?
>
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
> ---------------------------------------------------------------------
> 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
Re: AW: [C2] handle-errors with content aggregation
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
giacomo a écrit :
<snip/>
> >
> > [Sorry for this late answer, it's hard to follow the list these days]
> >
> > The servlet API provides some methods to check if the servlet engine's
> > output buffer has been flushed to the client browser
> > (ServletResponse.isCommited) and, if no, to reset this buffer
> > (ServletResponse.reset).
> >
> > Before calling the error-handler, the sitemap could reset the response
> > if possible. This would allow for a higher probability of having clean
> > error pages displayed to the user.
> >
> > Does it make sense ?
>
> It make sense to me. So, patch the error handler :)
>
> Giacomo
>
Done on the main branch.
Carsten, should I commit it also on 2.0 now, or after beta 2 ?
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2] handle-errors with content aggregation
Posted by giacomo <gi...@apache.org>.
On Tue, 17 Jul 2001, Sylvain Wallez wrote:
>
>
> Carsten Ziegeler a écrit :
> >
> > > Donald Ball wrote:
> > >
> > > On Thu, 12 Jul 2001, Carsten Ziegeler wrote:
> > >
> > > > With the current design of cocoon2 it is not possible to have always a
> > > > clean error page.
> > > > The problem is that the components, e.g. the content aggregation write
> > > > directly to the output stream. If some components have written something
> > > > and an error occurs it is forbidden by the servlet engine to do
> > > a redirect
> > > > and the output stream cannot be reset.
> > > >
> > > > I wanted to address this problem by the concept of an
> > > intermediate output
> > > > stream, but there is currently no consense found.
> > >
> > > consensus seemed to be that an intermediate output stream was fine as long
> > > as we could configure it on or off on a per-sitemap or per-pipeline basis.
> > > that was my impression anyway. does anyone disagree with this?
> > >
> > 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.
> > And the other think is, if the stream is directly written to the
> > output stream, the error handling is not working properly as
> > the result can consist of the first part of the real response followed
> > by the error information. This is really bad.
> >
> > Carsten
> > > - donald
> > >
>
> [Sorry for this late answer, it's hard to follow the list these days]
>
> The servlet API provides some methods to check if the servlet engine's
> output buffer has been flushed to the client browser
> (ServletResponse.isCommited) and, if no, to reset this buffer
> (ServletResponse.reset).
>
> Before calling the error-handler, the sitemap could reset the response
> if possible. This would allow for a higher probability of having clean
> error pages displayed to the user.
>
> Does it make sense ?
It make sense to me. So, patch the error handler :)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2] handle-errors with content aggregation
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler a écrit :
>
> > Donald Ball wrote:
> >
> > On Thu, 12 Jul 2001, Carsten Ziegeler wrote:
> >
> > > With the current design of cocoon2 it is not possible to have always a
> > > clean error page.
> > > The problem is that the components, e.g. the content aggregation write
> > > directly to the output stream. If some components have written something
> > > and an error occurs it is forbidden by the servlet engine to do
> > a redirect
> > > and the output stream cannot be reset.
> > >
> > > I wanted to address this problem by the concept of an
> > intermediate output
> > > stream, but there is currently no consense found.
> >
> > consensus seemed to be that an intermediate output stream was fine as long
> > as we could configure it on or off on a per-sitemap or per-pipeline basis.
> > that was my impression anyway. does anyone disagree with this?
> >
> 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.
> And the other think is, if the stream is directly written to the
> output stream, the error handling is not working properly as
> the result can consist of the first part of the real response followed
> by the error information. This is really bad.
>
> Carsten
> > - donald
> >
[Sorry for this late answer, it's hard to follow the list these days]
The servlet API provides some methods to check if the servlet engine's
output buffer has been flushed to the client browser
(ServletResponse.isCommited) and, if no, to reset this buffer
(ServletResponse.reset).
Before calling the error-handler, the sitemap could reset the response
if possible. This would allow for a higher probability of having clean
error pages displayed to the user.
Does it make sense ?
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
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
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Torsten Curdt wrote:
>
> > > > With the current design of cocoon2 it is not possible to
> have always a
> > > > clean error page.
> > > > The problem is that the components, e.g. the content
> aggregation write
> > > > directly to the output stream. If some components have
> written something
> > > > and an error occurs it is forbidden by the servlet engine to do
> > > a redirect
> > > > and the output stream cannot be reset.
> > > >
> > > > I wanted to address this problem by the concept of an
> > > intermediate output
> > > > stream, but there is currently no consense found.
> > >
> > > consensus seemed to be that an intermediate output stream was
> fine as long
> > > as we could configure it on or off on a per-sitemap or
> per-pipeline basis.
> > > that was my impression anyway. does anyone disagree with this?
> > >
> > 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
>
> Well, I think the sitemap designer has to think about stuff like
> this anyway... if the pipeline is internal only or not... stuff
> like that.
>
Yes, this is right, but internal or not is more a "security" problem,
that means, you have to decide which content is available to the
world.
But deciding which "streaming method" is used is a pure technical
decision which no sitemap editor wants to deal with. Usually he
doesn't know about such things and does not have to care about them.
> > should be directly written or "cached" and then written.
>
> I think we will loose a lot of a speed impression if we
> go back to the C1 behavior!
>
> > And the other think is, if the stream is directly written to the
> > output stream, the error handling is not working properly as
> > the result can consist of the first part of the real response followed
> > by the error information. This is really bad.
>
> Well, that is for sure true! But since I hope people don't see
> it too often I would go for the performance ;)
Yes, believe me or not, but I thought something like that, too.
I thought that perhaps this could be configurable not on the
pipeline level but in general, like caching or not (in the cocoon.xconf).
For production sites you would use the performance solution
and for developing the slow one with the nice error messages.
Carsten
> --
> Torsten
>
> ---------------------------------------------------------------------
> 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
RE: [C2] handle-errors with content aggregation
Posted by Torsten Curdt <tc...@dff.st>.
> > > With the current design of cocoon2 it is not possible to have always a
> > > clean error page.
> > > The problem is that the components, e.g. the content aggregation write
> > > directly to the output stream. If some components have written something
> > > and an error occurs it is forbidden by the servlet engine to do
> > a redirect
> > > and the output stream cannot be reset.
> > >
> > > I wanted to address this problem by the concept of an
> > intermediate output
> > > stream, but there is currently no consense found.
> >
> > consensus seemed to be that an intermediate output stream was fine as long
> > as we could configure it on or off on a per-sitemap or per-pipeline basis.
> > that was my impression anyway. does anyone disagree with this?
> >
> 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
Well, I think the sitemap designer has to think about stuff like
this anyway... if the pipeline is internal only or not... stuff
like that.
> should be directly written or "cached" and then written.
I think we will loose a lot of a speed impression if we
go back to the C1 behavior!
> And the other think is, if the stream is directly written to the
> output stream, the error handling is not working properly as
> the result can consist of the first part of the real response followed
> by the error information. This is really bad.
Well, that is for sure true! But since I hope people don't see
it too often I would go for the performance ;)
--
Torsten
---------------------------------------------------------------------
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
Re: [C2] handle-errors with content aggregation: not for ResourceNotFound???
Posted by Jan Uyttenhove <ja...@pandora.be>.
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
Re: AW: [C2] handle-errors with content aggregation
Posted by Donald Ball <ba...@webslingerZ.com>.
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
AW: [C2] handle-errors with content aggregation
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Donald Ball wrote:
>
> On Thu, 12 Jul 2001, Carsten Ziegeler wrote:
>
> > With the current design of cocoon2 it is not possible to have always a
> > clean error page.
> > The problem is that the components, e.g. the content aggregation write
> > directly to the output stream. If some components have written something
> > and an error occurs it is forbidden by the servlet engine to do
> a redirect
> > and the output stream cannot be reset.
> >
> > I wanted to address this problem by the concept of an
> intermediate output
> > stream, but there is currently no consense found.
>
> consensus seemed to be that an intermediate output stream was fine as long
> as we could configure it on or off on a per-sitemap or per-pipeline basis.
> that was my impression anyway. does anyone disagree with this?
>
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.
And the other think is, if the stream is directly written to the
output stream, the error handling is not working properly as
the result can consist of the first part of the real response followed
by the error information. This is really bad.
Carsten
> - 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
Re: AW: [C2] handle-errors with content aggregation
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 12 Jul 2001, Carsten Ziegeler wrote:
> With the current design of cocoon2 it is not possible to have always a
> clean error page.
> The problem is that the components, e.g. the content aggregation write
> directly to the output stream. If some components have written something
> and an error occurs it is forbidden by the servlet engine to do a redirect
> and the output stream cannot be reset.
>
> I wanted to address this problem by the concept of an intermediate output
> stream, but there is currently no consense found.
consensus seemed to be that an intermediate output stream was fine as long
as we could configure it on or off on a per-sitemap or per-pipeline basis.
that was my impression anyway. does anyone disagree with this?
- donald
---------------------------------------------------------------------
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
Posted by Carsten Ziegeler <cz...@sundn.de>.
With the current design of cocoon2 it is not possible to have always a
clean error page.
The problem is that the components, e.g. the content aggregation write
directly to the output stream. If some components have written something
and an error occurs it is forbidden by the servlet engine to do a redirect
and the output stream cannot be reset.
I wanted to address this problem by the concept of an intermediate output
stream, but there is currently no consense 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
================================================================
>>>>>>
Hi all,
I'm currently working on a site that frequently uses content aggregation.
But when an error occurs, I should be able to show a nice error page, not
the standard cocoon error page. So now I'm trying to use the handle-errors
for this purpose, but I have some problems when an error occurs in a part of
a aggregated page.
An example:
<map:aggregate element="page">
<map:part src="header.xml" element="header"/>
<map:part src="left.xml" element="left"/>
<map:part src="middle.xml" element="middle"/>
<map:part src="footer" element="footer"/>
</map:aggregate>
and
<map:handle-errors>
<map:transform src="stylesheets/system/error2html.xsl"/>
<map:serialize status-code="500"/>
</map:handle-errors>
When an error occurs while generating the part middle.xml, I get a page
containing header, left and the (transformed) cocoon error, but no footer.
This is not exactly what I want, so I tried a redirect to a static error
page inside the handle-errors block:
<map:handle-errors>
<map:redirect-to uri="errorpage"/>
</map:handle-errors>
This doesn't work either, I get:
(...)
DEBUG 64521 [cocoon ] (Thread-6): Sitemap: session='false',
redirecting to 'errorpage'
DEBUG 64521 [cocoon ] (Thread-6): Sending redirect to 'errorpage'
ERROR 64521 [cocoon ] (Thread-6): error notifier barfs
java.lang.IllegalStateException: Response has already been committed
at
org.apache.tomcat.facade.HttpServletResponseFacade.sendError(HttpServletResp
onseFacade.java:204)
at
org.apache.tomcat.facade.HttpServletResponseFacade.sendRedirect(HttpServletR
esponseFacade.java:230)
at
org.apache.cocoon.environment.http.HttpResponse.sendRedirect(HttpResponse.ja
va:84)
at
org.apache.cocoon.environment.http.HttpEnvironment.redirect(HttpEnvironment.
java:106)
at
org.apache.cocoon.www.sitemap_xmap.error_process_1(sitemap_xmap.java:5035)
at org.apache.cocoon.www.sitemap_xmap.process(sitemap_xmap.java:5003)
at org.apache.cocoon.www.sitemap_xmap.process(sitemap_xmap.java:1245)
at org.apache.cocoon.sitemap.Handler.process(Handler.java:175)
at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:94)
at org.apache.cocoon.Cocoon.process(Cocoon.java:293)
at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:471)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
(...)
which makes sense, as my header part and left part of the aggregation have
already been committed, right?
So I can't redirect here, because I'm handling errors in one part of my
aggregation, and the first two parts have already been committed.
But if I handle errors of a part of the aggregation, and of the aggregation
itself, then why isn't the last part of the aggregation displayed?
And what can I do to simple show an error page, without any remaining
aggregation parts?
Any suggestions?
Thanx,
Jan
___________________________________________________
Jan Uyttenhove
- Software Engineer -
The E-corporation
Roderveldlaan 3 bus 1
B-2600 Antwerpen
Guldensporenpark 10 (Axxes 51-003)
B-9820 Merelbeke-Gent
T:+32 [0]9 272.22.00
F:+32 [0]9 272.22.11
______________________________________
- Good company for the road ahead - www.the-ecorp.com
<<<<<<<
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org