cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [SITEMAP] The order of processing
Date Wed, 24 Apr 2002 16:00:35 GMT
Konstantin Piroumian wrote:

>I'm getting a strange behavior of the sitemap processor. Here goes the
>1. Preliminaries:
>/samples/sitemap.xmap - automounted from the root sitemap
>/samples/i18n/sitemap.xmap - automounted from the samples sitemap
>By default, samples sitemap displays directory listing of the mounted
>directory, but in i18n sitemap I've added this matcher:
>                <!-- Default pipeline -->
>                <map:match pattern="">
>                    <map:redirect-to uri="cocoon:/simple.xml"/>
>                </map:match>
>So, now when an URL like '/cocoon/samples/i18n/' is requested the default
>page is displayed (and not the directory listing).
>The default (simple.xml) page is composed using aggregation from a menu (at
>left) and the main content.
>2. The problem:
>Now the most funny part starts. I send request to the default URL and get a
>page that contains 3 parts! Those are: the menu as it should be, content
>part truncated at the bottom and THE DIRECTORY LISTING attached to the
>bottom of the page! So, the result is composed from TWO sitemaps at the same
>time. But i18n sitemap contains absolutely no references to its parent!
>Call to the '/cocoon/samples/i18n/simple.xml' returns a page without the
>directory listing.
>3. Cause
>Logs show that the content part throws multiple Exceptions (that are, BTW,
>related to the latest backward incompatible changes in I18nTransformer). So,
>I suspect that the processing went like this:
>            <map:aggregate element="site">
>                <map:part src="cocoon:/menu/{../0}"/>  <!-- === OK === -->
>                <map:part src="cocoon:/content/{../0}" label="content"/>
><!-- === ERROR during transformation === -->
>                <!-- === Output from the parent sitemap is included here
>=== -->
>            </map:aggregate>
>4. Questions:
>Am I doing something wrong/unnatural with the sitemap?

Doesn't seem so...

>What should be the correct behavior of sitemap processor in such cases?
>Is it possible to return 500 status if one of the parts in aggregation

In case of internal requests (i.e. "cocoon:"), exceptions other than 
ConnectionResetException and ResourceNotFoundException are propagated to 
the caller.

Following the chain of components that participate in your aggregation, 
I found that ContentAggregator has a "finally" block to force the 
closing of the root tag and the document before propagating the 
exception. This IMO is bad, because an exception occuring in the parts 
means the document is not complete, and worse, there may be some opened 
elements that have not been closed. And calling endDocument() in the 
finally block triggers the transformation by Xalan (if there's no 
incremental processing), certainly leading to strange results.

Now I don't know where this directory listing come from...

Konstantin, could you please try again after having commented out the 
finally block in ContentAggregator (line 156) ? And if the directory 
listing still comes out, can you search the logs for a treeprocessor 
matching info message before a call to the directory generator ?

>Why the parent sitemap is invoked on error?

The matching info messages gives the sitemap file and line number. This 
can help us to find our way in the various mount points.

>Thanks for any answers/comments/bugfixes!

Hope this helps !


Sylvain Wallez
 Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message