Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: domain of grek@tuffmail.com designates
 216.86.168.178 as permitted sender)
Message-ID: <45BDD5C7.4090100@tuffmail.com>
Date: Mon, 29 Jan 2007 12:08:55 +0100
From: Grzegorz Kossakowski <grek@tuffmail.com>
User-Agent: Thunderbird 1.5.0.9 (X11/20060911)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: ${cocoon.request.contextPath} returns null in 2.2
References: <45BBBCF0.1000002@tuffmail.com> <45BCFD51.3080205@nada.kth.se>
 <45BDBC85.4090205@nada.kth.se>
In-Reply-To: <45BDBC85.4090205@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 8bit

Daniel Fagerstrom napisa�(a):
> Daniel Fagerstrom skrev:
>> Grzegorz Kossakowski wrote:
>>> Hello,
>>>
>>> I'm hacking now ajax and forms block to get them use of
>>> servlet-services
>>> and came across a bug. When you put ${cocoon.request.contextPath} into
>>> JX template it will always return null (at least while using servlet
>>> dispatcher). However, ${cocoon.request.requestURI} returns valid value,
>>> so it must be only contextPath broken somehow. Unfortunately, I have no
>>> skills to debug this.
>>> Anyone can at least confirm this? Can you test it without servlet
>>> dispatcher? (I would do it myself if I knew how)
>>>   
>> I have not tested it. But looking at the code the servlet dispatcher
>> just embeds the request object from the servlet container with a
>> proxy. And the proxy doesn't affect the contextPath AFAICS, so it
>> might be that the context path is null in the original request.
>>
>> For a servlet service that is called through the servlet protocol,
>> the contextPath will always be "", which is a bug. Currently the
>> request object of the calling servlet service is not available in the
>> servlet source, so there is no easy fix. I plan to refactor the call
>> stack and make it available there.
>>
>> In the servlet architecture we have:
>>
>> requestURI = contextPath + servletPath + pathInfo
>>
>> As the servlet service architecture creates an extra level of paths
>> relative to the servlet architecture there are several possibilities
>> where to add the mountPath.  I solved it in the following way: the
>> dispatcher servlet will look for the mountPath that is the longest
>> prefix in the incoming pathInfo. It will then create a new
>> servletPath and pathInfo for the called servlet service:
>>
>> newServletPath = servletPath + mountPath
>> newPathInfo = pathInfo.substring(mountPath.length())
>>
>> So as you can see the contextPath will be the same as for all servlet
>> services.
> Taking a look at your patches in JIRA I see that you have replaced
>  {request:contextPath}/_cocoon/resources
> with
>  /blocks-test/cocoon-forms-impl/resources
>
> Now the original pattern is actually faulty (even if it seem to be
> used everywhere in the samples), it should have been
>  {request:contextPath}{request:servletPath}/_cocoon/resources
> and
>  {request:contextPath}{request:servletPath}/resources
> in your refactored code.
>
> The only reason that the samples work is that the web.xml in
> cocoon-webapp mounts the sitemap servlet at "/*" which gives
> servletPath="", but there is no reason to constrain the use of the
> sitemap servlet to be used only with an empty servlet path. A servlet
> is supposed to be mountable wherever the user want it.
>
> Using the servlet service fw, sitemap servlets will be mounted at
> other paths and the servletPath must be taken into account.
Thanks for explanation. However, your proposed solution will not work.
In cocoon-ajax-sample we have:
<script type="text/javascript"
src="/blocks-test/cocoon-ajax-impl/resources/dojo/dojo.js"/>
Now if it is replaced by:
<script type="text/javascript"
src="${cocoon.request.contextPath}${cocoon.request.servletPath}/resources
/resources/dojo/dojo.js"/>
It would be resolved into:
<script type="text/javascript"
src="/blocks-test/cocoon-ajax-sample/resources/dojo/dojo.js"/>

So in short, all we want is '/blocks-test' part, the rest depends on
which block's resources we link to. How get this part?
> It is still a bug that the contextPath is null, it should be "" (or
> some other non null string).

After reverting all my hacking with servlet-services-fw it works well.
Next time I'll check thing more carefully, sorry for the noise.

-- 
Grzegorz Kossakowski