You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Konstantin Piroumian <kp...@apache.org> on 2002/04/24 13:34:48 UTC
[SITEMAP] The order of processing
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?
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?
Why the parent sitemap is invoked on error?
Thanks for any answers/comments/bugfixes!
Regards,
Konstantin
_________________________________________
Konstantin Piroumian
Lead Developer
ICQ#: 2297575
( Work Tel#: +7 095 795 0520 * 1288
+ More ways to contact me
i See more about me
_________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SITEMAP] The order of processing
Posted by Konstantin Piroumian <kp...@apache.org>.
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:sylvain@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [SITEMAP] The order of processing
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org