Konstantin Piroumian wrote:
>G'day!
>
>I'm getting a strange behavior of the sitemap processor. Here goes the
>problem.
>
>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
>fails?
>
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
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
