Re: error handling in aggregations

Jeremy Quinn Sun, 19 Mar 2006 04:10:52 -0800

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></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?



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-errors>s 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

Reply via email to