cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <vadim.gritse...@verizon.net>
Subject Re: Bug with context and subsitemaps
Date Tue, 15 Apr 2003 13:07:54 GMT
Björn Lütkemeier wrote:

>Hi,
>
>we noticed a bug that occurs when working with nested subsitemaps. Lets have
>a look at the following sitemap (I know its an abstract example, but I think
>it is therefore easy to understand ;-)):
>
>sitemap:
><map:pipeline>
>	<map:mount src="sub/sitemap.xmap" uri-prefix="sub"/> <!-- mount1 -->
></map:pipeline>
>
>sub/sitemap.xmap:
><map:pipeline>
>	<map:mount src="sub/sitemap.xmap" uri-prefix="sub"/> <!-- mount2 -->
>	<map:match pattern="**">
>		<map:generate src="any.xml"/>
>		...
>	</map:match>
></map:pipeline>
>
>sub/sub/sitemap.xmap:
><map:pipeline>
>	<map:match pattern="blah2">
>		...
>	</map:match>
></map:pipeline>
>
>Now when you call http://.../cocoon/sub/sub/blah1 Cocoon will step down to
>the sub/sub/sitemap, but find no match in it. Therefore it continues after
>mount2 and executes pipeline **. Now the generator throws an exception
>because file any.xml cannot be found. Why that?
>The problem can be found within the code of class AbstractEnvironment:
>
>public void setContext(String prefix, String uri) {
>	this.setContext(getRootContext()); /* WRONG!!! */
>	...
>}
>
>This method is called within class MountNode in the following way:
>
>String oldPrefix = env.getURIPrefix();
>String oldURI    = env.getURI();
>try {
>	env.changeContext(resolvedPrefix, resolvedSource);
>	... // process subsitemap
>} finally {
>	// Restore context
>	env.setContext(oldPrefix, oldURI);
>	...
>}
>
>It is of cause wrong, because setContext() must not set the context to the
>root context, which corresponds to the root sitemap, but to the one, that
>has been active before changeContext(..). Therefore file any.xml will be
>searched in the root directory, so its now clear why it cannot be found.
>
>We propose to add a method setContext(String prefix, String uri, URL
>context) to interface Environment and perhaps to deprecate the old/wrong
>one, so MountNode can reset the context correctly.
>
>Any comments / other ideas to fix the bug?
>

Seems that you are right in your findings. Carsten, can you comment?

What really bugs me is that this is not the first time this particular 
bug is being fixed... Can you guys in addition to bug fix supply test 
class for this bug?

Vadim




Mime
View raw message