-----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-----
