Sylvain,
seems that I've found some strange/funny things. Looks like a bug somewhere
in the error handler. So, what happens:
* First scenario (i18n sitemap is misconfigured):
1. I request the URL: 'cocoon/samples/i18n/' - this should invoke its own
sitemap
2. sitemap fails with an exception (and has no <handle-error /> in it)
3. parent sitemap's matcher is invoked (for mounted samples) and directory
listing comes out
4. no a single sign on the screen about the failed sitemap
Second scenario (with a proper i18n sitemap):
1. I request the URL: 'cocoon/samples/i18n/'
2. i18n sitemap is called, a pipeline is matched with no exceptions
3. an exception occures when aggregation is almost finished
then (I'm not sure for this part):
4. parent sitemap's error handler fails (as it does not find the
error2html.xsl stylesheet)
5. !!! default matcher is called and directory listing is generated !!! ;))
A comment on this. If you look at line 97 in /webapp/samples/sitemap.xmap
then you'll see that a stylesheet is referenced
("common/style/xsl/html/error2html.xsl"), the reference is correct and the
file is present. But if an exception occures somewhere in the mounted
sitemap then for an unknown reason the stylesheet is looked up not relative
to the current '/samples' context path, but a level higher:
'/cocoon/common/...' and not 'cocoon/samples/common'.
See below for my other comments:
> Konstantin Piroumian wrote:
>
> >
> >I'm getting a strange behavior of the sitemap processor. Here goes the
> >problem.
<skipped />
> >4. Questions:
...
>
> >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.
I've moved code from 'finally' block inside of the 'try' - no difference. I
still get the listing.
>
> Now I don't know where this directory listing come from...
It comes from the parent sitemap. But why - it's still a mistery for me.
>
> 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 ?
Here it is:
INFO (2002-04-25) 19:30.30:186 [sitemap](/cocoon/samples/i18n/)
HttpProcessor[8080][4]/PreparableMatchNode: Matcher 'wildcard' matched
prepared pattern '**/' at
file:/D:/JBuilder6/jakarta-tomcat-4.0.1/webapps/cocoon/sitemap.xmap:1199:29
So, the problem comes from the root sitemap and not the samples'! ;-(
When I change the path of error stylesheet then exception is displayed
instead of the listing. Screenshot with the stack trace you can find here:
http://kot-p.hotbox.ru/projects/cocoon/simple-exception.html
>
> >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.
Yes, this info is very useful!
Konstantin
>
> >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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
