Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.1.11
-
None
-
Patch available
Description
Let say I have a root sitemap not located in the webapp context, with a simple pipeline like :
{code:xml}
<map:match pattern="foo">
<map:read src="foo.png"/>
</map:match>
{code}
If I call directly, the URI /foo, I correctly get the image foo.png
Now, if I have a second sitemap elsewhere, mounted from the first one, with another simple pipeline like :
{code:xml}
<map:match pattern="bar">
<map:redirect-to uri="cocoon://foo"/>
</map:match>
{code}
If I call /foo/bar, I get a 404 Not Found saying that it looks for foo.png in the webapp context, and not relative to the root sitemap.
Looking at the code, I discovered that in the first case, in the method TreeProcessor.setupConcreteProcessor(), we have a statement especially for handling the case of sitemap not located in the webapp context :
{code:java}
if (this.parent == null) {
// Ensure root sitemap uses the correct context, even if not located in the webapp context
env.changeContext("", this.source.getURI());
}
{code}
while in the second case, where the ConcreteTreeProcessor is managed in the method ConcreteTreeProcessor.handleCocoonRedirect(), there's no such statement.
I'll provide a patch for fixing this, but looking deeper at the code, I found that this looked like a hack (even for the existing statement).
I think it would be better to have the right root context at the creation of the environment, and not to have to change it later when building the ConcreteTreeProcessor.
{code:xml}
<map:match pattern="foo">
<map:read src="foo.png"/>
</map:match>
{code}
If I call directly, the URI /foo, I correctly get the image foo.png
Now, if I have a second sitemap elsewhere, mounted from the first one, with another simple pipeline like :
{code:xml}
<map:match pattern="bar">
<map:redirect-to uri="cocoon://foo"/>
</map:match>
{code}
If I call /foo/bar, I get a 404 Not Found saying that it looks for foo.png in the webapp context, and not relative to the root sitemap.
Looking at the code, I discovered that in the first case, in the method TreeProcessor.setupConcreteProcessor(), we have a statement especially for handling the case of sitemap not located in the webapp context :
{code:java}
if (this.parent == null) {
// Ensure root sitemap uses the correct context, even if not located in the webapp context
env.changeContext("", this.source.getURI());
}
{code}
while in the second case, where the ConcreteTreeProcessor is managed in the method ConcreteTreeProcessor.handleCocoonRedirect(), there's no such statement.
I'll provide a patch for fixing this, but looking deeper at the code, I found that this looked like a hack (even for the existing statement).
I think it would be better to have the right root context at the creation of the environment, and not to have to change it later when building the ConcreteTreeProcessor.