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 +0000, 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:8888/test > > <?xml version="1.0" encoding="ISO-8859-1"?><site><content1/></ > > site><html><head><title>Resource Not Found</title><style><!--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: #800000; background- > > color: #ffff80;}a:active {color: #006666;}--></style></ > > head><body><h1>Resource Not Found</h1><p><span>Message:</span> > > Resource Not Found</p><p><span>Description:</span> The requested > > resource "/test" could not be found</p><p><span>Sender:</ > > span> org.apache.cocoon.servlet.CocoonServlet</p><p><span>Source:</ > > span> Cocoon Servlet</p><p 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 : > <site><content1/></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"?><site><content1/></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] > >
