Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E9C042A.6040900@verizon.net>
Date: Tue, 15 Apr 2003 09:07:54 -0400
From: Vadim Gritsenko <vadim.gritsenko@verizon.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Bug with context and subsitemaps
References: <NOEJIONLEDAKFJMPLNMGGEFGCAAA.bluetkemeier@s-und-n.de>
In-Reply-To: <NOEJIONLEDAKFJMPLNMGGEFGCAAA.bluetkemeier@s-und-n.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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