cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: [jira] Commented: (COCOON-2066) BlockCompletePathModule returns wrong path in scope of internal servlet call
Date Fri, 08 Jun 2007 14:18:07 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Daniel Fagerstrom wrote:
> Giacomo Pati skrev:
>> Grzegorz Kossakowski wrote:
>>> Giacomo Pati pisze:
>>>
>>>>> If you think about getServletPath() of HttpServletRequest hold in
>>>>> BlockCallHttpServletRequest it will return mount-path but not for the
>>>>> current servlet but for the servlet that called current servlet.
>>>> Than there is something wrong with it IMHO.
> 
> Agree, getServletPath() should return the mount-path for the current
> servlet.
> 
>>> Why do you think so? Object representing current request returns mount
>>> path were servlet processing current request in mounted at. What's wrong
>>> with it?
>>
>> If I understand the Servlet API correctly than:
>>
>> getContextPath should return the path where the webapp is mounted in
>> the Servlet-Container (root path)
>>
>> getServletPath should return the path where a specific Servlet is
>> mounted in the webapp according to
>> the web.xml mapping.
> 
> That is true, but doesn't help that much for servlet services, as their
> mountpath introduces a new level that not is covered by the contextPath
> + servletPath + pathInfo of the servlet spec. Still these are the path
> parts that are available in the servlet API so we need a reasonable
> mapping of the path parts inside a servlet service to these parts.
> 
> We discussed how to solve that in
> http://marc.info/?l=xml-cocoon-dev&m=117009688607351&w=2 and decided to
> use the mapping:
> 
> newContextPath = contextPath + servletPath
> newServletPath = mountPath
> newPathInfo = pathInfo.substring(mountPath.length())
> 
> when the DispatcherServlet calls a servlet service. See
> DynamicProxyRequestHandler#invoke, for the implementation. To be
> consistent with that for a situation where one servlet service calls
> another with an url "servlet:<callee>/<path>" we would need something like:
> 
> calleeContextPath = callerContextPath
> calleeServletPath = mountPath of called servlet service
> calleePathInfo = <path>
> 
> Thinking about it I don't think that there is anything hindering having
> two DispatcherServlets where a servlet service from one calls a servlet
> service from the other one. In this case the context path will be wrong
> and there is no easy way to solve it. But I don't think we need to care
> about such a subtle case.

I aggree on this: not allowing to have two DispatcherServlets (DS) configured

And thus the equations/assignments above should be:

calleeContextPath = same as the newContextPath (we only have one DS
calleeServletPath = mountPath alike newServletPath above
calleePathInfo = <path>

> Back to more important things: The request object constructed for the
> call need access to the "mountPath of called servlet service". I would
> propose to achieve this by letting the BlockCallHttpServletRequest
> having access to the servlet service context of the called servlet
> service. Then it can get the mount path by calling
> ServletServiceContext#getMountPath. The current servlet service context
> is also needed if we want a correct implementation of
> BlockCallHttpServletRequest#getRequestDispatcher.
> 
> /Daniel
> 

- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)

iD8DBQFGaWUfLNdJvZjjVZARAsIjAKDj6DfLRfcu9+WnDklO0SWDGF21gwCgnVmS
6crtMuC/tMPxmaRPb2rqiAI=
=gcN0
-----END PGP SIGNATURE-----

Mime
View raw message