cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject Re: error handling in aggregations
Date Sun, 19 Mar 2006 13:32:33 GMT
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.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: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 &quot;/test&quot; 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
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message