cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Pfingsthorn" <m.pfingsth...@hippo.nl>
Subject error handling causes NPE? (was: error handling in aggregations)
Date Tue, 21 Mar 2006 15:49:00 GMT
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:bruno@outerthought.org]
> > 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 &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