Re: [C3] Error handling in REST controller
On 12/19/2011 06:47 PM, Andreas Hartmann wrote: Hi all, I just noticed that if a handler method in a RESTController throws an exception and the sitemap doesn't contain an error handler, an empty response with status code 200 is returned. IMO this is not good. I see two approaches to improve it: A) The SpringRESTController sets the status code to 500 if an exception was thrown by the controller implementation. B) The sitemap processor should catch the exception (I'm not familiar with the implementation details yet) and send an appropriate response (on a side note, it would be nice to be able to set the status-code attribute for a Reader). I have to admit that the whole concept how the REST controller in combination with the sitemap should handle the request-response cycle is a bit unclear to me. Is the REST controller always in charge of the whole request-response cycle, up to setting the response status code? Is the handle-errors element in the sitemap obsolete when the REST controller is used? IMO this would make sense, since the REST controller is much closer to the HTTP details than classic G-T-S pipelines, where more stuff happened in the sitemap (selectors for HTTP methods, serializers with status-code attributes). Anyways, there should be a clear contract between the sitemap and the REST controller, something like: * The REST controller is responsible for setting up the response, including error handling. * The handle-errors clause kicks in if an error occurs in the REST controller itself. I'm not sure if we should introduce special error handling for REST controllers. Wouldn't we have to do the same for all other sitemap components either? If the author of a sitemap decides that he doesn't want to provide proper error handling, we should catch the error in o.a.c.servlet.RequestProcessor.sendSitemapResponse() and send 500 Internal Server Error so that the status code is correct. We should also log the exception there because AFAICS this isn't done anywhere else. Additionally we can give a hint in the log files that an error has occurred but wasn't handled properly by the sitemap o.a.c.sitemap.node.PipelineNode.handleException(). -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
[C3] Error handling in REST controller
Hi all, I just noticed that if a handler method in a RESTController throws an exception and the sitemap doesn't contain an error handler, an empty response with status code 200 is returned. IMO this is not good. I see two approaches to improve it: A) The SpringRESTController sets the status code to 500 if an exception was thrown by the controller implementation. B) The sitemap processor should catch the exception (I'm not familiar with the implementation details yet) and send an appropriate response (on a side note, it would be nice to be able to set the status-code attribute for a Reader). I have to admit that the whole concept how the REST controller in combination with the sitemap should handle the request-response cycle is a bit unclear to me. Is the REST controller always in charge of the whole request-response cycle, up to setting the response status code? Is the handle-errors element in the sitemap obsolete when the REST controller is used? IMO this would make sense, since the REST controller is much closer to the HTTP details than classic G-T-S pipelines, where more stuff happened in the sitemap (selectors for HTTP methods, serializers with status-code attributes). Anyways, there should be a clear contract between the sitemap and the REST controller, something like: * The REST controller is responsible for setting up the response, including error handling. * The handle-errors clause kicks in if an error occurs in the REST controller itself. WDYT? -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
Re: error handling in aggregations
* Max Pfingsthorn: Yes, this works well. I've tested it and with 'when=external' on 'map:handle-errors', it does stop the serializer from dumping the data before the error page. Also, 'when=internal' works wonderfully inside the aggregate! I would be all for this change before 2.1.9 comes out. If noone objects, I'll commit it within the hour. Hello Max, Thank you for taking care of this. But can you *please* document all the changes you make to status.xml? You didn't either mention the processing pipeline locking feature. Thanks, -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: error handling causes NPE? (was: error handling in aggregations)
Max Pfingsthorn schrieb: Hi! Err, guys, can it be that the sources aren't released correctly after a ProcessingException during pipeline execution? I get the same NPE I did when I didn't release a sitemap source correctly a while ago after I apply this patch to 2.1.8... Any ideas? Usually the pipeline components release the sources in their recycle() method. So could it be that you have a buggy component in your pipeline? PS: Can you apply your changes to the ContentAggregator to trunk as well, please? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
RE: error handling causes NPE? (was: error handling in aggregations)
Hi! Yes, I'll change the one in trunk as well today. It's funny, because I only use the ContentAggregator, the XMLSerializer and the FileGenerator. I have to investigate a little more in which configuration this actually happens, but I am fairly sure that the ContentAggregator (the only place where a SitemapSource is used) releases everything correctly. Since this only seems to happen when an Exception is thrown during processing, I thought that maybe there is an error deeper in the error handling code. Something like a missing finally... The error is rather hard to notice because if you use cocoon servlet, it actually doesn't show it. I noticed it in my little test project. I hope it's again something I did wrong, I'll keep you guys up to date. max -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 09:59 To: dev@cocoon.apache.org Subject: Re: error handling causes NPE? (was: error handling in aggregations) Max Pfingsthorn schrieb: Hi! Err, guys, can it be that the sources aren't released correctly after a ProcessingException during pipeline execution? I get the same NPE I did when I didn't release a sitemap source correctly a while ago after I apply this patch to 2.1.8... Any ideas? Usually the pipeline components release the sources in their recycle() method. So could it be that you have a buggy component in your pipeline? PS: Can you apply your changes to the ContentAggregator to trunk as well, please? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: error handling causes NPE? (was: error handling in aggregations)
* Max Pfingsthorn: Yes, I'll change the one in trunk as well today. Hello Max, While you're at it, there's also the AbstractCachingProcessingPipeline that needs an update in trunk. TIA, -- Jean-Baptiste Quenot http://caraldi.com/jbq/
RE: error handling causes NPE? (was: error handling in aggregations)
Hi! I know, but I haven't quite been able to use the samples. The changes to AbstractCachingProcessingPipeline are extensive and I wouldn't feel comfortable patching the trunk version without testing it first. (Changes to DefaultContentAggregator were very minor). Can someone point me to a guide how to get the samples running in trunk? max -Original Message- From: Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 16:54 To: dev@cocoon.apache.org Subject: Re: error handling causes NPE? (was: error handling in aggregations) * Max Pfingsthorn: Yes, I'll change the one in trunk as well today. Hello Max, While you're at it, there's also the AbstractCachingProcessingPipeline that needs an update in trunk. TIA, -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: error handling in aggregations
Many thanks for the links Vadim !! regards Jeremy On 20 Mar 2006, at 18:01, Vadim Gritsenko wrote: Jeremy Quinn wrote: On 20 Mar 2006, at 12:41, Bruno Dumon wrote: On Mon, 2006-03-20 at 12:00 +, Jeremy Quinn wrote: Lets say the aggregation part that is in error, is a cocoon:// pipeline, it is possible that the called pipeline has it's own local error-handler . if this is the case, it could be interesting to see if that one exception could run that one error-handler whose output would replace the output of that one aggregation part, instead of the whole pipeline. I can imagine this would be useful. Maybe it even works if the called pipeline has an error handler with when='internal' ? I had never seen this attribute before, or find any documentation all I can find is the code ... Vote Thread: http://marc.theaimsgroup.com/?t=11107614872r=1 Change Log (since changes.html is broken): http://marc.theaimsgroup.com/?l=xml-cocoon-devm=65425228965 Samples: http://svn.apache.org/viewcvs.cgi/cocoon/branches/BRANCH_2_1_X/src/ webapp/samples/errorhandling/ Vadim smime.p7s Description: S/MIME cryptographic signature
RE: error handling in aggregations
Hi!
Yes, this works well. I've tested it and with 'when=external' on
'map:handle-errors', it does stop the serializer from dumping the data before
the error page. Also, 'when=internal' works wonderfully inside the aggregate!
I would be all for this change before 2.1.9 comes out. If noone objects, I'll
commit it within the hour.
max
-Original Message-
From: Bruno Dumon [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 19, 2006 14:33
To: dev@cocoon.apache.org
Subject: Re: error handling in aggregations
On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote:
Hi All
Investigating this further, I came up with this simplest possible
sitemap to reproduce the problem :
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components
map:generators default=file
map:generator name=file label=content
logger=sitemap.generator.file pool-grow=4 pool-max=32 pool-
min=4 src=org.apache.cocoon.generation.FileGenerator/
/map:generators
map:serializers default=xml
map:serializer name=xml logger=sitemap.serializer.xml
mime-type=text/xml pool-grow=4 pool-max=32 pool-min=4
src=org.apache.cocoon.serialization.XMLSerializer/
/map:serializers
map:matchers default=wildcard
map:matcher logger=sitemap.matcher.wildcard
name=wildcard
src=org.apache.cocoon.matching.WildcardURIMatcher/
/map:matchers
map:pipes default=noncaching
map:pipe logger=sitemap.pipes.noncaching
name=noncaching
src=org.apache.cocoon.components.pipeline.impl.NonCachingProc
essingPipe
line
parameter name=outputBufferSize value=32768/
/map:pipe
/map:pipes
/map:components
map:pipelines
map:pipeline internal-only=false type=noncaching
map:match pattern=test
map:aggregate element=site
map:part element=content1 src=nothing.xml/
map:part element=content2 src=nothingelse.xml/
/map:aggregate
map:serialize type=xml /
/map:match
/map:pipeline
/map:pipelines
/map:sitemap
I set this up as the top-level sitemap, loaded by cocoon.xconf.
I access the url and I get this :
$ curl http://localhost:/test
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//
sitehtmlheadtitleResource Not Found/titlestyle!--body
{ background-color: white; color: black; font-family: verdana,
helvetica, sanf serif;}h1 {color: #336699; margin: 0px 0px
20px 0px;
border-width: 0px 0px 1px 0px; border-style: solid; border-color:
#336699;}p.footer { color: #336699; border-width: 1px 0px 0px 0px;
border-style: solid; border-color: #336699; }span {color: #336699;}
pre {padding-left: 20px;}a:link {font-weight: bold; color:
#336699;}
a:visited {color: #336699; }a:hover {color: #80; background-
color: #80;}a:active {color: #00;}--/style/
headbodyh1Resource Not Found/h1pspanMessage:/span
Resource Not Found/ppspanDescription:/span The requested
resource quot;/testquot; could not be found/ppspanSender:/
span org.apache.cocoon.servlet.CocoonServlet/ppspanSource:/
span Cocoon Servlet/pp class='footer'a href='http://
cocoon.apache.org/'Apache Cocoon 2.1.9-dev/p/body/html
Two outputs
First the content of the failed aggregation :
sitecontent1//site
Then the generic error message.
If I now comment out the line parameter name=outputBufferSize
value=32768/ from the map:pipe. then I only get the
error message.
I have tested this in 2.1.7 -- 2.1.9-dev.
I suspect this did not occur in 2.1.6.
Is this a bug, or is it what I should expect to happen if
an output
buffer is configured?
Hi Jeremy,
Given the streaming nature of the SAX pipeline, buffering the complete
output at the end of the pipeline is indeed the only way to reliably
recover from exceptions that might happen during its
execution. This is
not necessarily bad, as whatever other way you would solve this, you
would need to temporarily store the data in one way or another to be
able to recover from errors.
There's a little bit more to it though. In case of an error the output
your pipeline is quite small:
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//site
which is much less then your buffer size of 32768, so normally Cocoon
should still be able to reset the output before generating the error
page.
Someone asked the exact same question a week or two ago on the users
list, at which time I had a quick look into this. The cause
is that the
ContentAggregator class, which does the aggregation, will
still generate
the endDocument event in case an exception occurs. IMO, it
should not do
this (unless it would also catch the exception). Here is the relevant
fragment:
try {
SourceUtil.parse(this.manager, part.source
error handling causes NPE? (was: error handling in aggregations)
Hi!
Err, guys, can it be that the sources aren't released correctly after a
ProcessingException during pipeline execution? I get the same NPE I did when I
didn't release a sitemap source correctly a while ago after I apply this patch
to 2.1.8...
Any ideas?
max
-Original Message-
From: Max Pfingsthorn
Sent: Tuesday, March 21, 2006 16:33
To: dev@cocoon.apache.org
Subject: RE: error handling in aggregations
Hi!
Yes, this works well. I've tested it and with
'when=external' on 'map:handle-errors', it does stop the
serializer from dumping the data before the error page. Also,
'when=internal' works wonderfully inside the aggregate!
I would be all for this change before 2.1.9 comes out. If
noone objects, I'll commit it within the hour.
max
-Original Message-
From: Bruno Dumon [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 19, 2006 14:33
To: dev@cocoon.apache.org
Subject: Re: error handling in aggregations
On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote:
Hi All
Investigating this further, I came up with this simplest
possible
sitemap to reproduce the problem :
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components
map:generators default=file
map:generator name=file label=content
logger=sitemap.generator.file pool-grow=4 pool-max=32 pool-
min=4 src=org.apache.cocoon.generation.FileGenerator/
/map:generators
map:serializers default=xml
map:serializer name=xml
logger=sitemap.serializer.xml
mime-type=text/xml pool-grow=4 pool-max=32 pool-min=4
src=org.apache.cocoon.serialization.XMLSerializer/
/map:serializers
map:matchers default=wildcard
map:matcher logger=sitemap.matcher.wildcard
name=wildcard
src=org.apache.cocoon.matching.WildcardURIMatcher/
/map:matchers
map:pipes default=noncaching
map:pipe logger=sitemap.pipes.noncaching
name=noncaching
src=org.apache.cocoon.components.pipeline.impl.NonCachingProc
essingPipe
line
parameter name=outputBufferSize value=32768/
/map:pipe
/map:pipes
/map:components
map:pipelines
map:pipeline internal-only=false type=noncaching
map:match pattern=test
map:aggregate element=site
map:part element=content1 src=nothing.xml/
map:part element=content2 src=nothingelse.xml/
/map:aggregate
map:serialize type=xml /
/map:match
/map:pipeline
/map:pipelines
/map:sitemap
I set this up as the top-level sitemap, loaded by cocoon.xconf.
I access the url and I get this :
$ curl http://localhost:/test
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//
sitehtmlheadtitleResource Not
Found/titlestyle!--body
{ background-color: white; color: black; font-family: verdana,
helvetica, sanf serif;}h1 {color: #336699; margin: 0px 0px
20px 0px;
border-width: 0px 0px 1px 0px; border-style: solid;
border-color:
#336699;}p.footer { color: #336699; border-width: 1px 0px
0px 0px;
border-style: solid; border-color: #336699; }span {color:
#336699;}
pre {padding-left: 20px;}a:link {font-weight: bold; color:
#336699;}
a:visited {color: #336699; }a:hover {color: #80; background-
color: #80;}a:active {color: #00;}--/style/
headbodyh1Resource Not Found/h1pspanMessage:/span
Resource Not Found/ppspanDescription:/span The requested
resource quot;/testquot; could not be
found/ppspanSender:/
span
org.apache.cocoon.servlet.CocoonServlet/ppspanSource:/
span Cocoon Servlet/pp class='footer'a href='http://
cocoon.apache.org/'Apache Cocoon 2.1.9-dev/p/body/html
Two outputs
First the content of the failed aggregation :
sitecontent1//site
Then the generic error message.
If I now comment out the line parameter
name=outputBufferSize
value=32768/ from the map:pipe. then I only get the
error message.
I have tested this in 2.1.7 -- 2.1.9-dev.
I suspect this did not occur in 2.1.6.
Is this a bug, or is it what I should expect to happen if
an output
buffer is configured?
Hi Jeremy,
Given the streaming nature of the SAX pipeline, buffering
the complete
output at the end of the pipeline is indeed the only way to reliably
recover from exceptions that might happen during its
execution. This is
not necessarily bad, as whatever other way you would solve this, you
would need to temporarily store the data in one way or another to be
able to recover from errors.
There's a little bit more to it though. In case of an error
the output
your pipeline is quite small:
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//site
which is much less then your
Re: error handling in aggregations
Jeremy Quinn wrote: Many thanks for the links Vadim !! You *are* welcome, you know. No need for double exclamation marks ;-P Vadim regards Jeremy On 20 Mar 2006, at 18:01, Vadim Gritsenko wrote: Jeremy Quinn wrote: On 20 Mar 2006, at 12:41, Bruno Dumon wrote: On Mon, 2006-03-20 at 12:00 +, Jeremy Quinn wrote: Lets say the aggregation part that is in error, is a cocoon:// pipeline, it is possible that the called pipeline has it's own local error-handler . if this is the case, it could be interesting to see if that one exception could run that one error-handler whose output would replace the output of that one aggregation part, instead of the whole pipeline. I can imagine this would be useful. Maybe it even works if the called pipeline has an error handler with when='internal' ? I had never seen this attribute before, or find any documentation all I can find is the code ... Vote Thread: http://marc.theaimsgroup.com/?t=11107614872r=1 Change Log (since changes.html is broken): http://marc.theaimsgroup.com/?l=xml-cocoon-devm=65425228965 Samples: http://svn.apache.org/viewcvs.cgi/cocoon/branches/BRANCH_2_1_X/src/webapp/samples/errorhandling/ Vadim
Re: error handling in aggregations
Thanks for your reply Bruno,
On 19 Mar 2006, at 13:32, Bruno Dumon wrote:
On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote:
Hi All
Investigating this further, I came up with this simplest possible
sitemap to reproduce the problem :
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components
map:generators default=file
map:generator name=file label=content
logger=sitemap.generator.file pool-grow=4 pool-max=32 pool-
min=4 src=org.apache.cocoon.generation.FileGenerator/
/map:generators
map:serializers default=xml
map:serializer name=xml logger=sitemap.serializer.xml
mime-type=text/xml pool-grow=4 pool-max=32 pool-min=4
src=org.apache.cocoon.serialization.XMLSerializer/
/map:serializers
map:matchers default=wildcard
map:matcher logger=sitemap.matcher.wildcard name=wildcard
src=org.apache.cocoon.matching.WildcardURIMatcher/
/map:matchers
map:pipes default=noncaching
map:pipe logger=sitemap.pipes.noncaching name=noncaching
src=org.apache.cocoon.components.pipeline.impl.NonCachingProcessingP
ipe
line
parameter name=outputBufferSize value=32768/
/map:pipe
/map:pipes
/map:components
map:pipelines
map:pipeline internal-only=false type=noncaching
map:match pattern=test
map:aggregate element=site
map:part element=content1 src=nothing.xml/
map:part element=content2 src=nothingelse.xml/
/map:aggregate
map:serialize type=xml /
/map:match
/map:pipeline
/map:pipelines
/map:sitemap
I set this up as the top-level sitemap, loaded by cocoon.xconf.
I access the url and I get this :
$ curl http://localhost:/test
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//
sitehtmlheadtitleResource Not Found/titlestyle!--body
{ background-color: white; color: black; font-family: verdana,
helvetica, sanf serif;}h1 {color: #336699; margin: 0px 0px 20px 0px;
border-width: 0px 0px 1px 0px; border-style: solid; border-color:
#336699;}p.footer { color: #336699; border-width: 1px 0px 0px 0px;
border-style: solid; border-color: #336699; }span {color: #336699;}
pre {padding-left: 20px;}a:link {font-weight: bold; color: #336699;}
a:visited {color: #336699; }a:hover {color: #80; background-
color: #80;}a:active {color: #00;}--/style/
headbodyh1Resource Not Found/h1pspanMessage:/span
Resource Not Found/ppspanDescription:/span The requested
resource quot;/testquot; could not be found/ppspanSender:/
span org.apache.cocoon.servlet.CocoonServlet/ppspanSource:/
span Cocoon Servlet/pp class='footer'a href='http://
cocoon.apache.org/'Apache Cocoon 2.1.9-dev/p/body/html
Two outputs
First the content of the failed aggregation : sitecontent1//
site
Then the generic error message.
If I now comment out the line parameter name=outputBufferSize
value=32768/ from the map:pipe. then I only get the error
message.
I have tested this in 2.1.7 -- 2.1.9-dev.
I suspect this did not occur in 2.1.6.
Is this a bug, or is it what I should expect to happen if an output
buffer is configured?
Hi Jeremy,
Given the streaming nature of the SAX pipeline, buffering the complete
output at the end of the pipeline is indeed the only way to reliably
recover from exceptions that might happen during its execution.
This is
not necessarily bad, as whatever other way you would solve this, you
would need to temporarily store the data in one way or another to be
able to recover from errors.
Thanks for your explanation.
So I wonder why is this behaviour is 'fixed' when I turn off the buffer?
Or am I not actually turning off the buffer by removing that
parameter, just allowing it to be set to a different default value?
There's a little bit more to it though. In case of an error the output
your pipeline is quite small:
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//site
It is not normally that small, in my 'real' pipelines, there is far
more content.
which is much less then your buffer size of 32768, so normally Cocoon
should still be able to reset the output before generating the error
page.
Someone asked the exact same question a week or two ago on the users
list, at which time I had a quick look into this. The cause is that
the
ContentAggregator class, which does the aggregation, will still
generate
the endDocument event in case an exception occurs. IMO, it should
not do
this (unless it would also catch the exception). Here is the relevant
fragment:
try {
SourceUtil.parse(this.manager, part.source, this);
} finally {
if (part.element != null) {
endElem(part.element);
}
}
}
} finally {
endElem(this.rootElement);
this.contentHandler.endDocument();
}
I'd be in favor of removing these two finally blocks.
OK.
I suppose
Re: error handling in aggregations
On Mon, 2006-03-20 at 12:00 +, Jeremy Quinn wrote:
Thanks for your reply Bruno,
On 19 Mar 2006, at 13:32, Bruno Dumon wrote:
On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote:
Hi All
Investigating this further, I came up with this simplest possible
sitemap to reproduce the problem :
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components
map:generators default=file
map:generator name=file label=content
logger=sitemap.generator.file pool-grow=4 pool-max=32 pool-
min=4 src=org.apache.cocoon.generation.FileGenerator/
/map:generators
map:serializers default=xml
map:serializer name=xml logger=sitemap.serializer.xml
mime-type=text/xml pool-grow=4 pool-max=32 pool-min=4
src=org.apache.cocoon.serialization.XMLSerializer/
/map:serializers
map:matchers default=wildcard
map:matcher logger=sitemap.matcher.wildcard name=wildcard
src=org.apache.cocoon.matching.WildcardURIMatcher/
/map:matchers
map:pipes default=noncaching
map:pipe logger=sitemap.pipes.noncaching name=noncaching
src=org.apache.cocoon.components.pipeline.impl.NonCachingProcessingP
ipe
line
parameter name=outputBufferSize value=32768/
/map:pipe
/map:pipes
/map:components
map:pipelines
map:pipeline internal-only=false type=noncaching
map:match pattern=test
map:aggregate element=site
map:part element=content1 src=nothing.xml/
map:part element=content2 src=nothingelse.xml/
/map:aggregate
map:serialize type=xml /
/map:match
/map:pipeline
/map:pipelines
/map:sitemap
I set this up as the top-level sitemap, loaded by cocoon.xconf.
I access the url and I get this :
$ curl http://localhost:/test
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//
sitehtmlheadtitleResource Not Found/titlestyle!--body
{ background-color: white; color: black; font-family: verdana,
helvetica, sanf serif;}h1 {color: #336699; margin: 0px 0px 20px 0px;
border-width: 0px 0px 1px 0px; border-style: solid; border-color:
#336699;}p.footer { color: #336699; border-width: 1px 0px 0px 0px;
border-style: solid; border-color: #336699; }span {color: #336699;}
pre {padding-left: 20px;}a:link {font-weight: bold; color: #336699;}
a:visited {color: #336699; }a:hover {color: #80; background-
color: #80;}a:active {color: #00;}--/style/
headbodyh1Resource Not Found/h1pspanMessage:/span
Resource Not Found/ppspanDescription:/span The requested
resource quot;/testquot; could not be found/ppspanSender:/
span org.apache.cocoon.servlet.CocoonServlet/ppspanSource:/
span Cocoon Servlet/pp class='footer'a href='http://
cocoon.apache.org/'Apache Cocoon 2.1.9-dev/p/body/html
Two outputs
First the content of the failed aggregation : sitecontent1//
site
Then the generic error message.
If I now comment out the line parameter name=outputBufferSize
value=32768/ from the map:pipe. then I only get the error
message.
I have tested this in 2.1.7 -- 2.1.9-dev.
I suspect this did not occur in 2.1.6.
Is this a bug, or is it what I should expect to happen if an output
buffer is configured?
Hi Jeremy,
Given the streaming nature of the SAX pipeline, buffering the complete
output at the end of the pipeline is indeed the only way to reliably
recover from exceptions that might happen during its execution.
This is
not necessarily bad, as whatever other way you would solve this, you
would need to temporarily store the data in one way or another to be
able to recover from errors.
Thanks for your explanation.
So I wonder why is this behaviour is 'fixed' when I turn off the buffer?
Or am I not actually turning off the buffer by removing that
parameter, just allowing it to be set to a different default value?
Yes, by default the whole output is buffered before sending it to the
client. If you search for outputBufferSize in Cocoon's default root
sitemap you will find some information on this.
There's a little bit more to it though. In case of an error the output
your pipeline is quite small:
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//site
It is not normally that small, in my 'real' pipelines, there is far
more content.
which is much less then your buffer size of 32768, so normally Cocoon
should still be able to reset the output before generating the error
page.
Someone asked the exact same question a week or two ago on the users
list, at which time I had a quick look into this. The cause is that
the
ContentAggregator class, which does the aggregation, will still
generate
the endDocument event in case an exception occurs. IMO, it should
not do
this (unless it would also catch the exception). Here is the relevant
fragment:
Re: error handling in aggregations
On 20 Mar 2006, at 12:41, Bruno Dumon wrote:
On Mon, 2006-03-20 at 12:00 +, Jeremy Quinn wrote:
Thanks for your reply Bruno,
On 19 Mar 2006, at 13:32, Bruno Dumon wrote:
On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote:
Hi All
Investigating this further, I came up with this simplest possible
sitemap to reproduce the problem :
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components
map:generators default=file
map:generator name=file label=content
logger=sitemap.generator.file pool-grow=4 pool-max=32 pool-
min=4 src=org.apache.cocoon.generation.FileGenerator/
/map:generators
map:serializers default=xml
map:serializer name=xml logger=sitemap.serializer.xml
mime-type=text/xml pool-grow=4 pool-max=32 pool-min=4
src=org.apache.cocoon.serialization.XMLSerializer/
/map:serializers
map:matchers default=wildcard
map:matcher logger=sitemap.matcher.wildcard
name=wildcard
src=org.apache.cocoon.matching.WildcardURIMatcher/
/map:matchers
map:pipes default=noncaching
map:pipe logger=sitemap.pipes.noncaching
name=noncaching
src=org.apache.cocoon.components.pipeline.impl.NonCachingProcessin
gP
ipe
line
parameter name=outputBufferSize value=32768/
/map:pipe
/map:pipes
/map:components
map:pipelines
map:pipeline internal-only=false type=noncaching
map:match pattern=test
map:aggregate element=site
map:part element=content1 src=nothing.xml/
map:part element=content2 src=nothingelse.xml/
/map:aggregate
map:serialize type=xml /
/map:match
/map:pipeline
/map:pipelines
/map:sitemap
I set this up as the top-level sitemap, loaded by cocoon.xconf.
I access the url and I get this :
$ curl http://localhost:/test
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//
sitehtmlheadtitleResource Not Found/titlestyle!--body
{ background-color: white; color: black; font-family: verdana,
helvetica, sanf serif;}h1 {color: #336699; margin: 0px 0px 20px
0px;
border-width: 0px 0px 1px 0px; border-style: solid; border-color:
#336699;}p.footer { color: #336699; border-width: 1px 0px 0px 0px;
border-style: solid; border-color: #336699; }span {color: #336699;}
pre {padding-left: 20px;}a:link {font-weight: bold; color:
#336699;}
a:visited {color: #336699; }a:hover {color: #80; background-
color: #80;}a:active {color: #00;}--/style/
headbodyh1Resource Not Found/h1pspanMessage:/span
Resource Not Found/ppspanDescription:/span The requested
resource quot;/testquot; could not be found/ppspanSender:/
span org.apache.cocoon.servlet.CocoonServlet/ppspanSource:/
span Cocoon Servlet/pp class='footer'a href='http://
cocoon.apache.org/'Apache Cocoon 2.1.9-dev/p/body/html
Two outputs
First the content of the failed aggregation : sitecontent1//
site
Then the generic error message.
If I now comment out the line parameter name=outputBufferSize
value=32768/ from the map:pipe. then I only get the error
message.
I have tested this in 2.1.7 -- 2.1.9-dev.
I suspect this did not occur in 2.1.6.
Is this a bug, or is it what I should expect to happen if an output
buffer is configured?
Hi Jeremy,
Given the streaming nature of the SAX pipeline, buffering the
complete
output at the end of the pipeline is indeed the only way to reliably
recover from exceptions that might happen during its execution.
This is
not necessarily bad, as whatever other way you would solve this, you
would need to temporarily store the data in one way or another to be
able to recover from errors.
Thanks for your explanation.
So I wonder why is this behaviour is 'fixed' when I turn off the
buffer?
Or am I not actually turning off the buffer by removing that
parameter, just allowing it to be set to a different default value?
Yes, by default the whole output is buffered before sending it to the
client. If you search for outputBufferSize in Cocoon's default root
sitemap you will find some information on this.
Ah !! So by removing that parameter, you are not turning the buffer
off, you are setting it to unlimited size.
There's a little bit more to it though. In case of an error the
output
your pipeline is quite small:
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//site
It is not normally that small, in my 'real' pipelines, there is far
more content.
which is much less then your buffer size of 32768, so normally
Cocoon
should still be able to reset the output before generating the error
page.
Someone asked the exact same question a week or two ago on the users
list, at which time I had a quick look into this. The cause is that
the
ContentAggregator class, which does the aggregation, will still
generate
the endDocument event in case an exception occurs. IMO, it should
not do
this (unless it would also catch the exception). Here is the
relevant
fragment:
try {
Re: error handling in aggregations
Jeremy Quinn wrote: On 20 Mar 2006, at 12:41, Bruno Dumon wrote: On Mon, 2006-03-20 at 12:00 +, Jeremy Quinn wrote: Lets say the aggregation part that is in error, is a cocoon:// pipeline, it is possible that the called pipeline has it's own local error-handler . if this is the case, it could be interesting to see if that one exception could run that one error-handler whose output would replace the output of that one aggregation part, instead of the whole pipeline. I can imagine this would be useful. Maybe it even works if the called pipeline has an error handler with when='internal' ? I had never seen this attribute before, or find any documentation all I can find is the code ... Vote Thread: http://marc.theaimsgroup.com/?t=11107614872r=1 Change Log (since changes.html is broken): http://marc.theaimsgroup.com/?l=xml-cocoon-devm=65425228965 Samples: http://svn.apache.org/viewcvs.cgi/cocoon/branches/BRANCH_2_1_X/src/webapp/samples/errorhandling/ Vadim
Re: error handling in aggregations
Hi All
Investigating this further, I came up with this simplest possible
sitemap to reproduce the problem :
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components
map:generators default=file
map:generator name=file label=content
logger=sitemap.generator.file pool-grow=4 pool-max=32 pool-
min=4 src=org.apache.cocoon.generation.FileGenerator/
/map:generators
map:serializers default=xml
map:serializer name=xml logger=sitemap.serializer.xml
mime-type=text/xml pool-grow=4 pool-max=32 pool-min=4
src=org.apache.cocoon.serialization.XMLSerializer/
/map:serializers
map:matchers default=wildcard
map:matcher logger=sitemap.matcher.wildcard name=wildcard
src=org.apache.cocoon.matching.WildcardURIMatcher/
/map:matchers
map:pipes default=noncaching
map:pipe logger=sitemap.pipes.noncaching name=noncaching
src=org.apache.cocoon.components.pipeline.impl.NonCachingProcessingPipe
line
parameter name=outputBufferSize value=32768/
/map:pipe
/map:pipes
/map:components
map:pipelines
map:pipeline internal-only=false type=noncaching
map:match pattern=test
map:aggregate element=site
map:part element=content1 src=nothing.xml/
map:part element=content2 src=nothingelse.xml/
/map:aggregate
map:serialize type=xml /
/map:match
/map:pipeline
/map:pipelines
/map:sitemap
I set this up as the top-level sitemap, loaded by cocoon.xconf.
I access the url and I get this :
$ curl http://localhost:/test
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//
sitehtmlheadtitleResource Not Found/titlestyle!--body
{ background-color: white; color: black; font-family: verdana,
helvetica, sanf serif;}h1 {color: #336699; margin: 0px 0px 20px 0px;
border-width: 0px 0px 1px 0px; border-style: solid; border-color:
#336699;}p.footer { color: #336699; border-width: 1px 0px 0px 0px;
border-style: solid; border-color: #336699; }span {color: #336699;}
pre {padding-left: 20px;}a:link {font-weight: bold; color: #336699;}
a:visited {color: #336699; }a:hover {color: #80; background-
color: #80;}a:active {color: #00;}--/style/
headbodyh1Resource Not Found/h1pspanMessage:/span
Resource Not Found/ppspanDescription:/span The requested
resource quot;/testquot; could not be found/ppspanSender:/
span org.apache.cocoon.servlet.CocoonServlet/ppspanSource:/
span Cocoon Servlet/pp class='footer'a href='http://
cocoon.apache.org/'Apache Cocoon 2.1.9-dev/p/body/html
Two outputs
First the content of the failed aggregation : sitecontent1//site
Then the generic error message.
If I now comment out the line parameter name=outputBufferSize
value=32768/ from the map:pipe. then I only get the error message.
I have tested this in 2.1.7 -- 2.1.9-dev.
I suspect this did not occur in 2.1.6.
Is this a bug, or is it what I should expect to happen if an output
buffer is configured?
Thanks
regards Jeremy
On 16 Mar 2006, at 18:00, Jeremy Quinn wrote:
Hi All
I am working on a project that uses a lot of aggregations in the
sitemap, using map:aggregate.
My aggregated parts all call cocoon:// pipelines in other
subsitemap, via the top level sitemap, where my top-level sitemap
is not the one that comes built-in with Cocoon, but is my own,
mounted directly from cocoon.xconf (this does not seem to make any
difference).
I have one top-level map:handle-errors.
When an exception occurs in one of the aggregate parts eg.
o.a.e.s.SourceException, this is what appears to happen :
the outer pipeline carries on regardless, producing normal content
(just missing that part)
the error-handler outputs it's content
Result : two consecutive html/ pages in one request !!
I have tried every combination I can think of, in terms of the
placement of other map:handle-errorss in the other subsitemaps,
or their pipelines. All result in multiple html pages in one request.
I am working around this by having a map:handle-errors that
outputs the simplest possible html 'br/', which gets added after
the closing /html tag of my page, but does not seem to cause
problems in the browser.
I am actually using Cocoon 2.1.7, but I see little difference
between ContentAggregator.java in either version.
I have either misconfigured my sitemap to cause this behaviour, or
there are bugs in the aggregator.
What I would expect to happen if an aggregated part throws an
exception, is that the output of the map:handle-errors would
replace the content of that one failed part.
Has anyone else experienced this problem?
Thanks
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: error handling in aggregations
On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote:
Hi All
Investigating this further, I came up with this simplest possible
sitemap to reproduce the problem :
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components
map:generators default=file
map:generator name=file label=content
logger=sitemap.generator.file pool-grow=4 pool-max=32 pool-
min=4 src=org.apache.cocoon.generation.FileGenerator/
/map:generators
map:serializers default=xml
map:serializer name=xml logger=sitemap.serializer.xml
mime-type=text/xml pool-grow=4 pool-max=32 pool-min=4
src=org.apache.cocoon.serialization.XMLSerializer/
/map:serializers
map:matchers default=wildcard
map:matcher logger=sitemap.matcher.wildcard name=wildcard
src=org.apache.cocoon.matching.WildcardURIMatcher/
/map:matchers
map:pipes default=noncaching
map:pipe logger=sitemap.pipes.noncaching name=noncaching
src=org.apache.cocoon.components.pipeline.impl.NonCachingProcessingPipe
line
parameter name=outputBufferSize value=32768/
/map:pipe
/map:pipes
/map:components
map:pipelines
map:pipeline internal-only=false type=noncaching
map:match pattern=test
map:aggregate element=site
map:part element=content1 src=nothing.xml/
map:part element=content2 src=nothingelse.xml/
/map:aggregate
map:serialize type=xml /
/map:match
/map:pipeline
/map:pipelines
/map:sitemap
I set this up as the top-level sitemap, loaded by cocoon.xconf.
I access the url and I get this :
$ curl http://localhost:/test
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//
sitehtmlheadtitleResource Not Found/titlestyle!--body
{ background-color: white; color: black; font-family: verdana,
helvetica, sanf serif;}h1 {color: #336699; margin: 0px 0px 20px 0px;
border-width: 0px 0px 1px 0px; border-style: solid; border-color:
#336699;}p.footer { color: #336699; border-width: 1px 0px 0px 0px;
border-style: solid; border-color: #336699; }span {color: #336699;}
pre {padding-left: 20px;}a:link {font-weight: bold; color: #336699;}
a:visited {color: #336699; }a:hover {color: #80; background-
color: #80;}a:active {color: #00;}--/style/
headbodyh1Resource Not Found/h1pspanMessage:/span
Resource Not Found/ppspanDescription:/span The requested
resource quot;/testquot; could not be found/ppspanSender:/
span org.apache.cocoon.servlet.CocoonServlet/ppspanSource:/
span Cocoon Servlet/pp class='footer'a href='http://
cocoon.apache.org/'Apache Cocoon 2.1.9-dev/p/body/html
Two outputs
First the content of the failed aggregation : sitecontent1//site
Then the generic error message.
If I now comment out the line parameter name=outputBufferSize
value=32768/ from the map:pipe. then I only get the error message.
I have tested this in 2.1.7 -- 2.1.9-dev.
I suspect this did not occur in 2.1.6.
Is this a bug, or is it what I should expect to happen if an output
buffer is configured?
Hi Jeremy,
Given the streaming nature of the SAX pipeline, buffering the complete
output at the end of the pipeline is indeed the only way to reliably
recover from exceptions that might happen during its execution. This is
not necessarily bad, as whatever other way you would solve this, you
would need to temporarily store the data in one way or another to be
able to recover from errors.
There's a little bit more to it though. In case of an error the output
your pipeline is quite small:
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//site
which is much less then your buffer size of 32768, so normally Cocoon
should still be able to reset the output before generating the error
page.
Someone asked the exact same question a week or two ago on the users
list, at which time I had a quick look into this. The cause is that the
ContentAggregator class, which does the aggregation, will still generate
the endDocument event in case an exception occurs. IMO, it should not do
this (unless it would also catch the exception). Here is the relevant
fragment:
try {
SourceUtil.parse(this.manager, part.source, this);
} finally {
if (part.element != null) {
endElem(part.element);
}
}
}
} finally {
endElem(this.rootElement);
this.contentHandler.endDocument();
}
I'd be in favor of removing these two finally blocks.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
error handling in aggregations
Hi All I am working on a project that uses a lot of aggregations in the sitemap, using map:aggregate. My aggregated parts all call cocoon:// pipelines in other subsitemap, via the top level sitemap, where my top-level sitemap is not the one that comes built-in with Cocoon, but is my own, mounted directly from cocoon.xconf (this does not seem to make any difference). I have one top-level map:handle-errors. When an exception occurs in one of the aggregate parts eg. o.a.e.s.SourceException, this is what appears to happen : the outer pipeline carries on regardless, producing normal content (just missing that part) the error-handler outputs it's content Result : two consecutive html/ pages in one request !! I have tried every combination I can think of, in terms of the placement of other map:handle-errorss in the other subsitemaps, or their pipelines. All result in multiple html pages in one request. I am working around this by having a map:handle-errors that outputs the simplest possible html 'br/', which gets added after the closing /html tag of my page, but does not seem to cause problems in the browser. I am actually using Cocoon 2.1.7, but I see little difference between ContentAggregator.java in either version. I have either misconfigured my sitemap to cause this behaviour, or there are bugs in the aggregator. What I would expect to happen if an aggregated part throws an exception, is that the output of the map:handle-errors would replace the content of that one failed part. Has anyone else experienced this problem? Thanks regards Jeremy smime.p7s Description: S/MIME cryptographic signature
[jira] Created: (COCOON-1767) Error handling
Error handling -- Key: COCOON-1767 URL: http://issues.apache.org/jira/browse/COCOON-1767 Project: Cocoon Type: New Feature Components: - Blocks Framework Reporter: Reinhard Poetz There is sophisticated creation of error messages in the CocoonServlet, where is the right place for it in the blocks architecture? (by Daniel Fagerstrom: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113889468124728w=2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Refactored (again) XSLT error handling
Hi all, I refactored the error handling in TraxTransformer (again) and XSLTProcessor. * A usable xsl:message terminate=yes We were used to have Stylesheet directed termination on screen, indicating we had to dig in the logs. We now have the message displayed, with location information. * XSLT compilation warnings reported as errors. Xalan is very forgiving and reports many incorrect syntaxes (unknown attributes, text in forbidden places, etc) as warnings, which was leading incorrect stylesheets to be silently accepted. This means that some of your stylesheets may have to be fixed :-) Activating this second feature requires to change the XSLTProcessor implementation to o.a.c.c.xslt.XSLTProcessorImpl to connect the TransformerFactory to Cocoon's implementation of ErrorListener. This has been done in our code base, but existing applications will have to update their cocoon.xconf. Enjoy, Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Refactored (again) XSLT error handling
Sylvain Wallez wrote: snip/ Activating this second feature requires to change the XSLTProcessor implementation to o.a.c.c.xslt.XSLTProcessorImpl Damn! While porting to the 2.1 branch, I realized that this conflict with the same class that exists in the deprecated block. What do you think: is it better to remove the old XSLTProcessorImpl, or rename the new class? I like simple and straightforward names for default implementations... Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Refactored (again) XSLT error handling
Sylvain Wallez wrote: Sylvain Wallez wrote: snip/ Activating this second feature requires to change the XSLTProcessor implementation to o.a.c.c.xslt.XSLTProcessorImpl Damn! While porting to the 2.1 branch, I realized that this conflict with the same class that exists in the deprecated block. What do you think: is it better to remove the old XSLTProcessorImpl, or rename the new class? I like simple and straightforward names for default implementations... Sylvain Follow the versioning contract. Assuming you can find it. Ralph
Re: Refactored (again) XSLT error handling
Ralph Goers wrote: Sylvain Wallez wrote: Sylvain Wallez wrote: snip/ Activating this second feature requires to change the XSLTProcessor implementation to o.a.c.c.xslt.XSLTProcessorImpl Damn! While porting to the 2.1 branch, I realized that this conflict with the same class that exists in the deprecated block. What do you think: is it better to remove the old XSLTProcessorImpl, or rename the new class? I like simple and straightforward names for default implementations... Follow the versioning contract. Assuming you can find it. Uh? Versioning contract? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Refactored (again) XSLT error handling
Sylvain Wallez wrote: Ralph Goers wrote: Sylvain Wallez wrote: Sylvain Wallez wrote: snip/ Activating this second feature requires to change the XSLTProcessor implementation to o.a.c.c.xslt.XSLTProcessorImpl Damn! While porting to the 2.1 branch, I realized that this conflict with the same class that exists in the deprecated block. What do you think: is it better to remove the old XSLTProcessorImpl, or rename the new class? I like simple and straightforward names for default implementations... Follow the versioning contract. Assuming you can find it. Uh? Versioning contract? Sylvain Yes. Some time ago we voted on how long things had to be deprecated before they could be removed. For example, if the old' XSLTProcessorImpl was deprecated in 2.1.6 then it can be removed in 2.1.8 (or something like that - I don't remember off the top of my head). If so, the deprecated version can be removed and you can add your new one. I thought that what was voted on was put on the web site somewhere but I can't find it. Ralph
Re: Refactored (again) XSLT error handling
Sylvain Wallez wrote: Sylvain Wallez wrote: snip/ Activating this second feature requires to change the XSLTProcessor implementation to o.a.c.c.xslt.XSLTProcessorImpl Damn! While porting to the 2.1 branch, I realized that this conflict with the same class that exists in the deprecated block. I renamed it to o.a.c.c.xslt.TraxProcessor, so no more name clash with the deprecated class. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
DO NOT REPLY [Bug 32213] - Error handling and subsitemaps - errors not handled in subsitemap in special cases
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=32213. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=32213 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-06-03 17:07 --- See exception handling samples - lots of different scenarios, including this one, are working just fine. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Error Handling, him or me ???
Hi devers here again after not finding an answer in user, sorry. My problem concerns using map:handle-errors It seems I must be doing something wrong, because on a simple not-found exeption, everything goes great...hmmm...he finds the file(error.html) I give in sitemap...but then when I visit a proper page the error.html page I had shown stays as a header of any new page...weird. Also Sometimes, some pages simply go blank ?? and I get a [java] 17:09:12.632 WARN!! Error for /cocoo (my not found resource) [java] java.lang.StackOverflowError in console. offcourse all I have to do is comment out the map:handle-errors and all is fine again. so I ask myself is it bugged or am I ? I can't get it to be stable. Is anybody familiar with this problem ? has anybody managed to set up an error handler stabely? Thanks Regards Tibor Maybe this will help SiteMap Exception declaration ** map:selectors default=browser map:selector logger=sitemap.selector.exception name=exception src=org.apache.cocoon.selection.ExceptionSelector exception class=org.apache.cocoon.ResourceNotFoundException name=not-found/ exception class=org.apache.cocoon.components.flow.InvalidContinuationException name=invalid-continuation/ !-- The statement below tells the selector to unroll as much exceptions as possible -- exception class=java.lang.Throwable unroll=true/ /map:selector My Handler ** map:handle-errors map:select type=exception map:when test=not-found map:generate src=public/error.xml/ map:call resource=xslt_i18n_xhtml/ /map:when /map:select /map:handle-errors
Re: Error Handling, him or me ???
oceatoon wrote: Hi devers here again after not finding an answer in user, sorry. My problem concerns using map:handle-errors It seems I must be doing something wrong, because on a simple not-found exeption, everything goes great...hmmm...he finds the file(error.html) I give in sitemap...but then when I visit a proper page the error.html page I had shown stays as a header of any new page...weird. Also Sometimes, some pages simply go blank ?? and I get a [java] 17:09:12.632 WARN!! Error for /cocoo (my not found resource) [java] java.lang.StackOverflowError in console. offcourse all I have to do is comment out the map:handle-errors and all is fine again. so I ask myself is it bugged or am I ? I can't get it to be stable. Is anybody familiar with this problem ? has anybody managed to set up an error handler stabely? Well, error handlers have been reported to be working fine for years... Is the page where this problem occurs the main request, or is there some surrounding environment such as aggregation, cocoon: et al? Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Error Handling, him or me ???
Hi Sylvain Well, error handlers have been reported to be working fine for years... Yes that's what I figured, Is the page where this problem occurs the main request, or is there some surrounding environment such as aggregation, cocoon: et al? no very basic error handler.it sends an xhtml serialize on a not found resource. Well, I got it to work but maybe this is interesting or should simply not be used this way, even though the sample does. When I put it into a map:pipeline tag it works fine :D but when I put it in the global map:pipelines context that's when things go wrong as described. Do you use it in the global pipelines or in the a map:pipeline ? Thanks for the help Regards PS: you guys get our full support for the Tree structure widget, great idea, loads of applications, we'll be there to use it, why not use javascript Tree structures though?
Re: [VOTE] Internal Pipelines Error Handling
Sylvain Wallez wrote: Yep. And that shows that it's really a feature of handle-errors and not of pipeline. Ok, deal! :-) Patch landed in SVN, includes samples - take a look... Vadim
Re: [VOTE] Internal Pipelines Error Handling
Vadim Gritsenko wrote:
Hi All,
I'd implemented error handling for internal pipelines which allows to
discard content generated by the internal pipeline and replace it
instead with the content generated by the error-handler of the
internal pipeline. This feature is activated only when pipeline has an
attribute set:
map:pipeline internal-error-handling=true
This naming makes IMO more think to an added feature (yeah, that what it
is) rather than to an intrinsic feature of the sitemap engine (what it
should have been).
So what about map:pipeline handle-errors=external|internal|all the
default being external as of today?
Or even better, let's put this information on the handle-error statement
itself, because it's really where it belongs:
map:handle-errors when=external|internal|always
When attribute is missing or set to false, error handling behaviour is
as it is currently. Limitation of current implementation of the
feature is that only one, the inner most one error handler will be
used for error handling. Implementation can be extended to support
hierarchical error handlers, but I followed KISS and YAGNI approaches.
Internal requests have the problem that pipeline execution occurs out of
the control of the sitemap engine. Does the above restriction apply to
pipeline build-time or pipeline execution-time?
Because it's getting pretty close to the code freeze, I'd like to run
this through the vote. So, please vote here:
[X] Let's include this feature into 2.1.7 release!
With a better naming and with a clear description of the current
limitations (and the fact that they may be removed in the future)
[ ] No, it can wait...
And here:
[ ] Single error handler is just what we need.
[ ] No, it must support hierarchical error handling.
And here is place for suggestions:
[X] I don't like attribute abive and propose following
configuration attribute and values: ...
See above !
[ ] I suggest ...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [VOTE] Internal Pipelines Error Handling
Sylvain Wallez wrote: Vadim Gritsenko wrote: map:pipeline internal-error-handling=true Or even better, let's put this information on the handle-error statement itself, because it's really where it belongs: Only problem I see with it is that it opens up a scenario: map:pipeline ... map:handle-errors when=internal ... /map:handle-errors map:handle-errors when=external ... /map:handle-errors /map:pipeline And I'm not sure we want to go there. Hence, attribute on the pipeline itself is better, IMHO. It indicates that this is a feature of the pipeline (similar to internal-only=true). OTOH, using handle-errors attribute allows for: map:pipelines map:pipeline ... /map:pipeline map:handle-errors when=always ... /map:handle-errors /map:pipeline Which otherwise would require attribute on map:pipelines, if that feature is needed at all. map:handle-errors when=external|internal|always Isn't map:handle-errors when=internal FS? What would be the scenario for having error handler for internal but not external requests? When attribute is missing or set to false, error handling behaviour is as it is currently. Limitation of current implementation of the feature is that only one, the inner most one error handler will be used for error handling. Implementation can be extended to support hierarchical error handlers, but I followed KISS and YAGNI approaches. Internal requests have the problem that pipeline execution occurs out of the control of the sitemap engine. Does the above restriction apply to pipeline build-time or pipeline execution-time? Yes, good catch. I implemented single error handler for pipeline processing time. Pipeline assembly stage can use hierarchical handlers. Vadim Because it's getting pretty close to the code freeze, I'd like to run this through the vote. So, please vote here: [X] Let's include this feature into 2.1.7 release! With a better naming and with a clear description of the current limitations (and the fact that they may be removed in the future) [ ] No, it can wait... And here: [ ] Single error handler is just what we need. [ ] No, it must support hierarchical error handling. And here is place for suggestions: [X] I don't like attribute abive and propose following configuration attribute and values: ... See above ! [ ] I suggest ... Sylvain
Re: [VOTE] Internal Pipelines Error Handling
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
map:pipeline internal-error-handling=true
Or even better, let's put this information on the handle-error
statement itself, because it's really where it belongs:
Only problem I see with it is that it opens up a scenario:
map:pipeline
...
map:handle-errors when=internal
...
/map:handle-errors
map:handle-errors when=external
...
/map:handle-errors
/map:pipeline
And I'm not sure we want to go there. Hence, attribute on the pipeline
itself is better, IMHO. It indicates that this is a feature of the
pipeline (similar to internal-only=true).
The easy solution is to consider that there can be only one
map:handle-errors per map:pipeline! Currently, and for historical
reasons, there can be a combination of either :
map:handle-errors where the handler will need to have its own
generator
or
map:handle-errors type=404
map:handle-errors type=500
where the ErrorGenerator is automatically added.
The second form can be considered to be a deprecated legacy feature
(need to add logs for it, BTW), and we can therefore safely put the
when attribute on the first form (with no type attribute).
OTOH, using handle-errors attribute allows for:
map:pipelines
map:pipeline
...
/map:pipeline
map:handle-errors when=always
...
/map:handle-errors
/map:pipeline
Which otherwise would require attribute on map:pipelines, if that
feature is needed at all.
Yep. And that shows that it's really a feature of handle-errors and
not of pipeline.
map:handle-errors when=external|internal|always
Isn't map:handle-errors when=internal FS? What would be the
scenario for having error handler for internal but not external requests?
Maybe a scenario where you want to have errors be handled by the servlet
engine?
When attribute is missing or set to false, error handling behaviour
is as it is currently. Limitation of current implementation of the
feature is that only one, the inner most one error handler will be
used for error handling. Implementation can be extended to support
hierarchical error handlers, but I followed KISS and YAGNI approaches.
Internal requests have the problem that pipeline execution occurs out
of the control of the sitemap engine. Does the above restriction
apply to pipeline build-time or pipeline execution-time?
Yes, good catch. I implemented single error handler for pipeline
processing time. Pipeline assembly stage can use hierarchical handlers.
Ok, cool.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
[VOTE] Internal Pipelines Error Handling
Hi All, I'd implemented error handling for internal pipelines which allows to discard content generated by the internal pipeline and replace it instead with the content generated by the error-handler of the internal pipeline. This feature is activated only when pipeline has an attribute set: map:pipeline internal-error-handling=true When attribute is missing or set to false, error handling behaviour is as it is currently. Limitation of current implementation of the feature is that only one, the inner most one error handler will be used for error handling. Implementation can be extended to support hierarchical error handlers, but I followed KISS and YAGNI approaches. Because it's getting pretty close to the code freeze, I'd like to run this through the vote. So, please vote here: [ ] Let's include this feature into 2.1.7 release! [ ] No, it can wait... And here: [ ] Single error handler is just what we need. [ ] No, it must support hierarchical error handling. And here is place for suggestions: [ ] I don't like attribute abive and propose following configuration attribute and values: ... [ ] I suggest ... Background reading: This feature has been discussed and/or mentioned at least couple of times already, for example, in this thread: http://marc.theaimsgroup.com/?t=10842340133r=1 Thanks, Vadim
Re: [VOTE] Internal Pipelines Error Handling
... [X ] Let's include this feature into 2.1.7 release! ... [ X] Single error handler is just what we need. No too sure about this but why not start simpler and expand if use-cases show the need for hierarchical handling [ ] No, it must support hierarchical error handling. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: error handling
Due to time constraints I worked around it and lowered the priority on my TODO list. Feel free to take over :-) I'd love to. But since I have only glanced at the sitemap processing I have a feeling it will be a hack. Also, I'm up to my eyeballs trying to figure out what Pluto has in mind with Portlet Preferences so I can get Cocoon to do something useful, and I have to get that done first. But any advice on where changes would need to be made would be helpful. Sorry for the late reply ...well, for more information than already given in the thread you propably need to bug Mr. Sitemap Wallez for guidance ;-) cheers -- Torsten
RE: error handling
There was quite a discussion here regarding this, the last posted message of which seems to be http://marc.theaimsgroup.com/?l=xml-cocoon-devm=108670415314132w=2. Was anything ever done about this? We are running into problems with this in the Portal. Ralph Hunsberger, Peter said: Torsten Curdt [EMAIL PROTECTED] asks: After further investigations it seems like exceptions are passed to the error handler inside the treeprocessor. But requests using the cocoon protcol don't go through the treeprocessor the same way as external ones. So basically error handling is missing - or broken for such internal requests. I think this is a vital feature and I am wondering why noone hit that before. We came across this and I had assumed it was intentional. I believe there was some discussion about changing this, but I can't find the thread. Spoke too quick, have a look at: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107402329728352w=2 I can find my message: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107402329728352w=2 Where it turns out that the problem was because the pipeline was internal...
Re: error handling
Ralph Goers wrote: There was quite a discussion here regarding this, the last posted message of which seems to be http://marc.theaimsgroup.com/?l=xml-cocoon-devm=108670415314132w=2. Was anything ever done about this? We are running into problems with this in the Portal. Due to time constraints I worked around it and lowered the priority on my TODO list. Feel free to take over :-) cheers -- Torsten
Re: error handling
Torsten Curdt said: Ralph Goers wrote: There was quite a discussion here regarding this, the last posted message of which seems to be http://marc.theaimsgroup.com/?l=xml-cocoon-devm=108670415314132w=2. Was anything ever done about this? We are running into problems with this in the Portal. Due to time constraints I worked around it and lowered the priority on my TODO list. Feel free to take over :-) I'd love to. But since I have only glanced at the sitemap processing I have a feeling it will be a hack. Also, I'm up to my eyeballs trying to figure out what Pluto has in mind with Portlet Preferences so I can get Cocoon to do something useful, and I have to get that done first. But any advice on where changes would need to be made would be helpful. Ralph
DO NOT REPLY [Bug 32213] New: - Error handling and subsitemaps - errors not handled in subsitemap in special cases
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=32213.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32213
Error handling and subsitemaps - errors not handled in subsitemap in special
cases
Summary: Error handling and subsitemaps - errors not handled in
subsitemap in special cases
Product: Cocoon 2
Version: Current SVN 2.1
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Consider this code:
=
root sitemap:
map:match pattern=*/**
map:mount uri-prefix={1} check-reload=yes src={1}/sitemap.xmap
reload-method=synchron/
/map:match
map:match pattern=*/**.html
[...]
map:aggregate element=site
map:part src=cocoon:/{1}/{2}/
[...]
/map:aggregate
[...]
/map:match
=
subsitemap :
map:pipeline
map:match pattern=sth
[...]
/map:match
map:handle-errors
[...]
/map:handle-errors
/map:pipeline
Now, lets try this URL: subsite/sth.html; sth pipeline throws
exception but it will never reach handle-errors block in subsitemap.
It's handled by root sitemap exception handler.
I check it out even with no exception selector.
Well, I'm sure that's becouse of */**.html pipeline is first matched;
It looks like busting error handlig conception - subsitemap specific errors
shouldn't be handled in root sm.
Re: error handling
Torsten Curdt wrote:
...What about...
map:pipeline handle-errors=always|external|internal/
our current behaviour would be external.
I would like to have always andt the internal option might be FS ;)
+1 for the declaration, looks clean enough!
Carsten, I'd really like to takle this ASAP.
We are currently using a *very* ugly work around.
Sorry to jump in late.
This problem and possible discussions where discussed at [1], [2] and
follow-ups. The conclusion was that choosing to handle errors or not in
internal pipelines could be decided either by the caller or by the
callee depending on the use cases.
There's a technical difficulty, however, as internal requests are
handled differently than external ones when it comes to handling errors
occuring during pipeline execution (not during pipeline building).
- pipelines for external requests are executed as soon as the pipeline
is ended, i.e. in the map:serialize statement, hence under control of
the treeprocessor
- pipelines for internal requests are executed when getInputStream() or
toSAX() is called on the cocoon: source, out of the control of the
treeprocessor.
So we can add add handle-errors=always|external|internal and
?cocoon:handle-errors=true, but it will handle errors occuring during
the _building_ of the pipeline, and not during its _execution_.
Handling errors occuring during the execution of internal requests would
require some not so innocent changes in the pipeline machinery [3].
But we can of course go one step at a time and start by catching
pipeline build-time exceptions.
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107874417205088w=2
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107875707604536w=2
[3] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107876029119774w=2
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: error handling
Sorry to jump in late. Thanks for jumping in at all :) There's a technical difficulty, however, as internal requests are handled differently than external ones when it comes to handling errors occuring during pipeline execution (not during pipeline building). - pipelines for external requests are executed as soon as the pipeline is ended, i.e. in the map:serialize statement, hence under control of the treeprocessor - pipelines for internal requests are executed when getInputStream() or toSAX() is called on the cocoon: source, out of the control of the treeprocessor. Ok, but isn't the cocoon: source going back to treeprocessor after all? Or does it just setup the pipelines? I thought every request is goint through the TP. ...or who is passing the request to the pipeline(s)? So we can add add handle-errors=always|external|internal and ?cocoon:handle-errors=true, but it will handle errors occuring during the _building_ of the pipeline, and not during its _execution_. That's not what I am after. It does not help for error handling on aggregation. We should aim for the execution time. Handling errors occuring during the execution of internal requests would require some not so innocent changes in the pipeline machinery [3]. Well, IMHO this is major flaw and should be tackled. No matter if we need to change something or not. I think the pipeline machinery is so deep core that probably not to many people would notice anyway. Don't know... but maybe it would be possible to move the error handling further down to the pipeline level? If we are able to add that to the Abstract... classes even less people would be affected. But I have no clue if that's possible at all. Especially if we don't want to mix concerns. But we can of course go one step at a time and start by catching pipeline build-time exceptions. Not sure if that's worth the effort. I'd propose to change what needs to be changed. cheers -- Torsten
RE: error handling
Torsten Curdt wrote: Ok, but isn't the cocoon: source going back to treeprocessor after all? Or does it just setup the pipelines? I thought every request is goint through the TP. The cocoon: protocol is going through the TP for setting up the pipeline. The assembled pipeline component is returned to the protocol (Source) and from there directly invoked. So during execution of the pipeline the TP is not involved at all. So we can add add handle-errors=always|external|internal and ?cocoon:handle-errors=true, but it will handle errors occuring during the _building_ of the pipeline, and not during its _execution_. That's not what I am after. It does not help for error handling on aggregation. We should aim for the execution time. Yepp, execution time is imho more important - if we can do both, great :) I'd propose to change what needs to be changed. Yes :) I think, Sylvain outlined here http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107876029119774w=2 what has to be done. It should be fairly easy to add this to control the error handling at execution time. Controlling the error handling on construction time is very easy as well. If we add this to 2.2-dev we can change things anyway (even interfaces if required). Carsten
Re: error handling
Torsten Curdt wrote:
Sorry to jump in late.
Thanks for jumping in at all :)
There's a technical difficulty, however, as internal requests are
handled differently than external ones when it comes to handling
errors occuring during pipeline execution (not during pipeline
building).
- pipelines for external requests are executed as soon as the
pipeline is ended, i.e. in the map:serialize statement, hence under
control of the treeprocessor
- pipelines for internal requests are executed when getInputStream()
or toSAX() is called on the cocoon: source, out of the control of
the treeprocessor.
Ok, but isn't the cocoon: source going back to treeprocessor after
all? Or does it just setup the pipelines? I thought every request is
goint through the TP.
...or who is passing the request to the pipeline(s)?
You have to consider the two distinct phases that occur when a request
is handled:
- building the pipeline (executing sitemap statements) : matchers,
action and flowscript are called, generator, transformers and serializer
are added to the pipeline.
- processing the pipeline. The generator's generate() method is called,
which starts the processing chain.
Building the pipeline is done by the TP. Execution of statements stops
when encountering a terminal statement, i.e. a serialize, read,
redirect or flowscript call.
Processing the pipeline is different for internal and external requests:
- for external requests, the TP starts the processing within the
terminal statement (e.g. serialize). The enclosing handle-errors can
then be handled correctly.
- for internal requests, the TP does *not* start the processing, but
gives back a filled pipeline object to the SitemapSource. The
SitemapSource starts the processing when the content of the source is
needed. This means that pipeline processing occurs out of the
handle-errors enclosing the serialize, and that errors occuring in
that phase cannot be handled (at least with the current architecture).
So we can add add handle-errors=always|external|internal and
?cocoon:handle-errors=true, but it will handle errors occuring
during the _building_ of the pipeline, and not during its _execution_.
That's not what I am after. It does not help for error handling on
aggregation. We should aim for the execution time.
It all depends where the errors occur in the aggregated pipelines: is it
when building the pipeline or when executing it?
Handling errors occuring during the execution of internal requests
would require some not so innocent changes in the pipeline machinery
[3].
Well, IMHO this is major flaw and should be tackled.
No matter if we need to change something or not. I think the pipeline
machinery is so deep core that probably not to many people would
notice anyway.
Don't know... but maybe it would be possible to move the error
handling further down to the pipeline level? If we are able to add
that to the Abstract... classes even less people would be affected.
But I have no clue if that's possible at all.
Especially if we don't want to mix concerns.
A solution that I proposed in [1] is that for internal processing, the
TP not only builds the pipeline, but also returns a pointer to the
error-handling statements wrapped in a Processor. That way, the
SitemapSource can call the appropriate error handling statements.
But we can of course go one step at a time and start by catching
pipeline build-time exceptions.
Not sure if that's worth the effort.
I'd propose to change what needs to be changed.
Sure :-)
Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107876029119774w=2
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: error handling
map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) +1 for the declaration, looks clean enough! Carsten, I'd really like to takle this ASAP. We are currently using a *very* ugly work around. Yes, yes, do it - you don't have to wait for my +1, I'm just a little committer who likes it when everyone ignores him. Silence always means: I'm not against it. alright :) cheers -- Torsten
RE: error handling
Vadim Gritsenko wrote: IIRC, last first friday we had a chat with Carsten about adding an attribute to the handle-errors/ or to the pipeline/ which will indicate what behavior is needed in case of internal request: throw exception or process handle-errors/. Carsten? Yes, nothing of that is implemented yet. The discussion started because of internal redirects. Now, in general the error handlers are never called for internal requests - that was a design decision. Starting with 2.1.5 we have one exception, internal redirects, so if you do a map:redirect-to uri=cocoon:/something/ then - and only then - the error handler of the internal pipeline is called. HTH? Carsten
RE: error handling
Carsten Ziegeler dijo: Vadim Gritsenko wrote: IIRC, last first friday we had a chat with Carsten about adding an attribute to the handle-errors/ or to the pipeline/ which will indicate what behavior is needed in case of internal request: throw exception or process handle-errors/. Carsten? Yes, nothing of that is implemented yet. The discussion started because of internal redirects. Now, in general the error handlers are never called for internal requests - that was a design decision. Starting with 2.1.5 we have one exception, internal redirects, so if you do a map:redirect-to uri=cocoon:/something/ then - and only then - the error handler of the internal pipeline is called. Hi Carsten: Can you post more about it? Seems like many people, including me ;-), is having troubles with the cocoon:/ protocol. Best Regards, Antonio Gallardo.
Re: error handling
IIRC, last first friday we had a chat with Carsten about adding an attribute to the handle-errors/ or to the pipeline/ which will indicate what behavior is needed in case of internal request: throw exception or process handle-errors/. Carsten? Sounds like a good plan. In fact I think it would be a good default behavior but anyway. Yes, nothing of that is implemented yet. The discussion started because of internal redirects. Now, in general the error handlers are never called for internal requests - that was a design decision. Starting with 2.1.5 we have one exception, internal redirects, so if you do a map:redirect-to uri=cocoon:/something/ then - and only then - the error handler of the internal pipeline is called. HTH? Well, it clarifies... ;) Thanks! ...but - I think we definitely need a way to handle errors inside internal pipeline calls! Otherwise there is just no way to handle errors in an aggregation appropriately. I am happy to do it ...if there are no objections. But where to place it? I reckon we either need to make the interal pipeline calls go through the same hook inside the treeprocessor or move the error handling further down into the pipeline code. WDYT? cheers -- Torsten
RE: error handling
Antonio Gallardo wrote: Carsten Ziegeler dijo: Vadim Gritsenko wrote: IIRC, last first friday we had a chat with Carsten about adding an attribute to the handle-errors/ or to the pipeline/ which will indicate what behavior is needed in case of internal request: throw exception or process handle-errors/. Carsten? Yes, nothing of that is implemented yet. The discussion started because of internal redirects. Now, in general the error handlers are never called for internal requests - that was a design decision. Starting with 2.1.5 we have one exception, internal redirects, so if you do a map:redirect-to uri=cocoon:/something/ then - and only then - the error handler of the internal pipeline is called. Hi Carsten: Can you post more about it? Seems like many people, including me ;-), is having troubles with the cocoon:/ protocol. Are you talking about 2.1.5 or CVS Head? CVS Head has a rewritten internal request handling that simply might have bugs, so we have to fix these bugs first before its really usable. Carsten
RE: error handling
Torsten Curdt wrote: IIRC, last first friday we had a chat with Carsten about adding an attribute to the handle-errors/ or to the pipeline/ which will indicate what behavior is needed in case of internal request: throw exception or process handle-errors/. Carsten? Sounds like a good plan. In fact I think it would be a good default behavior but anyway. Yes, nothing of that is implemented yet. The discussion started because of internal redirects. Now, in general the error handlers are never called for internal requests - that was a design decision. Starting with 2.1.5 we have one exception, internal redirects, so if you do a map:redirect-to uri=cocoon:/something/ then - and only then - the error handler of the internal pipeline is called. HTH? Well, it clarifies... ;) Thanks! ...but - I think we definitely need a way to handle errors inside internal pipeline calls! Otherwise there is just no way to handle errors in an aggregation appropriately. I am happy to do it ...if there are no objections. But where to place it? I reckon we either need to make the interal pipeline calls go through the same hook inside the treeprocessor or move the error handling further down into the pipeline code. I think we can use the available things. We discussed two solutions: specifying it at the call, like: cocoon:handle-error:/something or cocoon:/something?cocoon:handle-error=true (Note the ':' in the second example which is not allowed for usual request parameters). and specifying it in the called pipeline: map:pipeline handle-errors-for-internal-calls=true/ The names of the attributes/request-parameters I used have not been set in the discussions. I just used here some to show the principle. Now, implementing this should be a two or three liner :) I already had it implemented but lost the code... Carsten
RE: error handling
Carsten Ziegeler dijo: Are you talking about 2.1.5 or CVS Head? CVS Head has a rewritten internal request handling that simply might have bugs, so we have to fix these bugs first before its really usable. Yep.!!! it tortures now for 2 days now! :( Best Regards, Antonio Gallardo
Re: error handling
I think we can use the available things. We discussed two solutions: specifying it at the call, like: cocoon:handle-error:/something or cocoon:/something?cocoon:handle-error=true Uaaahh maybe the first one - but this looks dead ugly and feels more like hack for what should be the default. ...or how would you explain a user that a pipeline behaves differenlty whether it's been called from the browser or from cocoon? (Note the ':' in the second example which is not allowed for usual request parameters). Noted - still ugly ;) and specifying it in the called pipeline: map:pipeline handle-errors-for-internal-calls=true/ This looks much better The names of the attributes/request-parameters I used have not been set in the discussions. I just used here some to show the principle. :-) What about... map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) Now, implementing this should be a two or three liner :) I already had it implemented but lost the code... You can also give me a hand ...up to you. cheers -- Torsten
Re: error handling
Le 4 juin 04, à 09:59, Torsten Curdt a écrit : ...What about... map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) +1 for the declaration, looks clean enough! -Bertrand
Re: error handling
...What about... map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) +1 for the declaration, looks clean enough! Carsten, I'd really like to takle this ASAP. We are currently using a *very* ugly work around. WDYT? cheers -- Torsten
RE: error handling
Torsten Curdt [EMAIL PROTECTED] writes: snipsort of ugly solution/snip and specifying it in the called pipeline: map:pipeline handle-errors-for-internal-calls=true/ This looks much better The names of the attributes/request-parameters I used have not been set in the discussions. I just used here some to show the principle. :-) What about... map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) Hmmm, just wondering, if I have: map:pipeline internal-only=true and I define a map:handle-errors within it, would that now work? And if it did, would I have to specify handle-errors=internal or would that be the default for such a pipeline? I realize, most people would likely only want a single handle-errors section so that you don't have to specify the same error handling in two different places. However, if someone did have a reason for having different handling for the two cases I'd expect that they'd want to add the handle-errors to the internal-only pipeline and not specify anything else. As such, handle-errors=internal does not seem necessary? Now, implementing this should be a two or three liner :) I already had it implemented but lost the code... You can also give me a hand ...up to you. cheers -- Torsten
Re: error handling
Hunsberger, Peter wrote: Torsten Curdt [EMAIL PROTECTED] writes: snipsort of ugly solution/snip and specifying it in the called pipeline: map:pipeline handle-errors-for-internal-calls=true/ This looks much better The names of the attributes/request-parameters I used have not been set in the discussions. I just used here some to show the principle. :-) What about... map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) Hmmm, just wondering, if I have: map:pipeline internal-only=true and I define a map:handle-errors within it, would that now work? And if it did, would I have to specify handle-errors=internal or would that be the default for such a pipeline? I realize, most people would likely only want a single handle-errors section so that you don't have to specify the same error handling in two different places. However, if someone did have a reason for having different handling for the two cases I'd expect that they'd want to add the handle-errors to the internal-only pipeline and not specify anything else. As such, handle-errors=internal does not seem necessary? It is necessary in case you don't want error handling in this internal pipeline -- meaning you want behavior as it is now. Now, if you want to change current default, you'll have to add this attribute. Vadim
RE: error handling
Vadim Gritsenko [EMAIL PROTECTED] writes: Hunsberger, Peter wrote: Torsten Curdt [EMAIL PROTECTED] writes: snipsort of ugly solution/snip and specifying it in the called pipeline: map:pipeline handle-errors-for-internal-calls=true/ This looks much better The names of the attributes/request-parameters I used have not been set in the discussions. I just used here some to show the principle. :-) What about... map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) Hmmm, just wondering, if I have: map:pipeline internal-only=true and I define a map:handle-errors within it, would that now work? And if it did, would I have to specify handle-errors=internal or would that be the default for such a pipeline? I realize, most people would likely only want a single handle-errors section so that you don't have to specify the same error handling in two different places. However, if someone did have a reason for having different handling for the two cases I'd expect that they'd want to add the handle-errors to the internal-only pipeline and not specify anything else. As such, handle-errors=internal does not seem necessary? It is necessary in case you don't want error handling in this internal pipeline -- meaning you want behavior as it is now. Huh? If you don't want error handling in an internal pipeline then just don't specify it. It doesn't work at the moment, so we're not taking anything away... Even if it did work, why would you want to handle external errors in an internal only pipeline? Now, if you want to change current default, you'll have to add this attribute. Now that seems like FS to me...
Re: error handling
Hunsberger, Peter wrote: Vadim Gritsenko [EMAIL PROTECTED] writes: ... Now, if you want to change current default, you'll have to add this attribute. Now that seems like FS to me... No, it's called backward compatibility ;-) Vadim
RE: error handling
Vadim Gritsenko [EMAIL PROTECTED] writes: Hunsberger, Peter wrote: Vadim Gritsenko [EMAIL PROTECTED] writes: ... Now, if you want to change current default, you'll have to add this attribute. Now that seems like FS to me... No, it's called backward compatibility ;-) Unless something has changed I don't think so: handle-errors does nothing in an internal-only pipeline, it doesn't work. So being backwards compatible with something that doesn't work isn't going to help anyone.
RE: error handling
Torsten Curdt wrote: ...What about... map:pipeline handle-errors=always|external|internal/ our current behaviour would be external. I would like to have always andt the internal option might be FS ;) +1 for the declaration, looks clean enough! Carsten, I'd really like to takle this ASAP. We are currently using a *very* ugly work around. Yes, yes, do it - you don't have to wait for my +1, I'm just a little committer who likes it when everyone ignores him. Silence always means: I'm not against it. Carsten
error handling
I have an interal pipeline which sometimes
throws an exception due to broken links.
map:pipeline
map:generate type=html src=get/{1}/
map:serialize type=xml/
map:handle-errors
map:generate src=default.xml/
map:serialize type=xml/
/map:handle-errors
/map:pipeline
And another one using it
map:pipeline
map:generate src=whatever.xml/
map:transform type=cinclude/ -- calls the intenal pipeline
...
/map:pipeline
Using the first pipeline works just
fine. Exceptions are being caught and
a default xml file is being presented
instead.
Unfortunately using it through the
second pipeline (through the cinclude
transformer) brings up the exception.
Anyone a clue what's happing here?
cheers
--
Torsten
Re: error handling
I have an interal pipeline which sometimes
throws an exception due to broken links.
map:pipeline
map:match pattern=..
map:generate type=html src=get/{1}/
map:serialize type=xml/
/map:match
map:handle-errors
map:generate src=default.xml/
map:serialize type=xml/
/map:handle-errors
/map:pipeline
And another one using it
map:pipeline
map:match patern=..
map:generate src=whatever.xml/
map:transform type=cinclude/ -- calls the intenal pipeline
...
/map:pipeline
...of course
We were discussing it here... does the cocoon
protocol create a new or use the existing
pipeline? ...if it's the same pipeline it
would explain the behaviour.
But IMHO it should work like in the
example above... WDYT?
cheers
--
Torsten
Re: error handling
After further investigations it seems like exceptions are passed to the error handler inside the treeprocessor. But requests using the cocoon protcol don't go through the treeprocessor the same way as external ones. So basically error handling is missing - or broken for such internal requests. I think this is a vital feature and I am wondering why noone hit that before. What do you guys think? Mr. Treeprocessor (Sylvain) and Mr. Pipeline (Carsten) in particular ;-) cheers -- Torsten
RE: error handling
Torsten Curdt [EMAIL PROTECTED] asks: After further investigations it seems like exceptions are passed to the error handler inside the treeprocessor. But requests using the cocoon protcol don't go through the treeprocessor the same way as external ones. So basically error handling is missing - or broken for such internal requests. I think this is a vital feature and I am wondering why noone hit that before. We came across this and I had assumed it was intentional. I believe there was some discussion about changing this, but I can't find the thread. I can find my message: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107402329728352w=2 Where it turns out that the problem was because the pipeline was internal...
RE: error handling
Torsten Curdt [EMAIL PROTECTED] asks: After further investigations it seems like exceptions are passed to the error handler inside the treeprocessor. But requests using the cocoon protcol don't go through the treeprocessor the same way as external ones. So basically error handling is missing - or broken for such internal requests. I think this is a vital feature and I am wondering why noone hit that before. We came across this and I had assumed it was intentional. I believe there was some discussion about changing this, but I can't find the thread. Spoke too quick, have a look at: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107402329728352w=2 I can find my message: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107402329728352w=2 Where it turns out that the problem was because the pipeline was internal...
Re: error handling
Torsten Curdt wrote:
I have an interal pipeline which sometimes
throws an exception due to broken links.
map:pipeline
map:generate type=html src=get/{1}/
map:serialize type=xml/
map:handle-errors
map:generate src=default.xml/
map:serialize type=xml/
/map:handle-errors
/map:pipeline
And another one using it
map:pipeline
map:generate src=whatever.xml/
map:transform type=cinclude/ -- calls the intenal pipeline
...
/map:pipeline
Using the first pipeline works just
fine. Exceptions are being caught and
a default xml file is being presented
instead.
Unfortunately using it through the
second pipeline (through the cinclude
transformer) brings up the exception.
Anyone a clue what's happing here?
IIRC, last first friday we had a chat with Carsten about adding an
attribute to the handle-errors/ or to the pipeline/ which will
indicate what behavior is needed in case of internal request: throw
exception or process handle-errors/. Carsten?
Vadim
Sample error handling shows a blank page
Hi: Here is another sample with problem. It show an blank page: http://localhost:/samples/errorhandling/exception/exception?exception=error Best Regards, Antonio Gallardo
Re: Sample error handling shows a blank page
Antonio Gallardo wrote: Here is another sample with problem. It show an blank page: http://localhost:/samples/errorhandling/exception/exception?exception=error That's intentional, AFAIR. At least under Tomcat - that's Tomcat's behavior in case of Error. I don't remember how it works with Jetty... Vadim
Re: Sample error handling shows a blank page
Vadim Gritsenko dijo: Antonio Gallardo wrote: Here is another sample with problem. It show an blank page: http://localhost:/samples/errorhandling/exception/exception?exception=error That's intentional, AFAIR. At least under Tomcat - that's Tomcat's behavior in case of Error. I don't remember how it works with Jetty... It was on jetty. I was using cocoon.sh servlet. If this is the right behavior, then we need at least describe what the user will expect. In my case I was not aware of that and to me this is a bad response. Sorry for the loud. Best Regards, Antonio Gallardo. Vadim
