cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Damioli (Created) (JIRA) <j...@apache.org>
Subject [jira] [Created] (COCOON-2319) Bad Environment context when redirecting to cocoon:// with a sitemap not located in the webapp context
Date Mon, 12 Dec 2011 09:20:31 GMT
Bad Environment context when redirecting to cocoon:// with a sitemap not located in the webapp
context
------------------------------------------------------------------------------------------------------

                 Key: COCOON-2319
                 URL: https://issues.apache.org/jira/browse/COCOON-2319
             Project: Cocoon
          Issue Type: Bug
          Components: * Cocoon Core
    Affects Versions: 2.1.11
            Reporter: Cédric Damioli
             Fix For: 2.1.12-dev (Current SVN)


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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message