You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Grzegorz Kossakowski (JIRA)" <ji...@apache.org> on 2007/05/23 14:58:16 UTC
[jira] Created: (COCOON-2066) BlockCompletePathModule returns wrong
path in scope of internal servlet call
BlockCompletePathModule returns wrong path in scope of internal servlet call
----------------------------------------------------------------------------
Key: COCOON-2066
URL: https://issues.apache.org/jira/browse/COCOON-2066
Project: Cocoon
Issue Type: Bug
Components: - Servlet service framework
Affects Versions: 2.2-dev (Current SVN)
Reporter: Grzegorz Kossakowski
BlockCompletePathModule uses this construct:
public Object getAttribute(String name, Configuration modeConf, Map objectModel) throws ConfigurationException {
return ObjectModelHelper.getRequest(objectModel).getContextPath() + blockPathModule.getAttribute(name, modeConf, objectModel);
}
However, when internal (service call or not) request is being made BlockCallHttpServletRequest becomes an object represnting current request but it has no meaningful representation of getContextPath method.
Solution to this problem might be forwarding context path value from original request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Giacomo Pati pisze:
>>
>> I can conform that it seems to work correct now. I've even tried to
>> mount the cocoon-webapp to
>> something different than root and the pathes to css a.s.o. are still
>> correct and the samples (I've
>> tested primarly the form samples) work fine.
>
> Thanks Giacomo for testing. I'm glad to hear that it works now. I'm
np
> sorry that I have taken over the issue that you were apparently
> interesting in fixing but I really wanted to resolve it ASAP.
- --
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)
iD4DBQFGZ8JKLNdJvZjjVZARArAdAJ90GYwOvmOutKDC93QZCmH9p0BrNACYgnsa
V71OK4bthUn7Ynvgm8jpcQ==
=IOFO
-----END PGP SIGNATURE-----
Re: [jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
>
> I can conform that it seems to work correct now. I've even tried to mount the cocoon-webapp to
> something different than root and the pathes to css a.s.o. are still correct and the samples (I've
> tested primarly the form samples) work fine.
Thanks Giacomo for testing. I'm glad to hear that it works now. I'm sorry that I have taken over the issue that you were apparently
interesting in fixing but I really wanted to resolve it ASAP.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: [jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502139 ]
>
> Grzegorz Kossakowski commented on COCOON-2066:
> ----------------------------------------------
>
> I have just committed the fix for this issue. Could someone test if it works correctly? Basically you need to run cocoon-webapp and check if http://localhost:8080/blocks/cocoon-forms-sample/ loads all resources correctly (especially css files).
> I would be grateful for any report.
I can conform that it seems to work correct now. I've even tried to mount the cocoon-webapp to
something different than root and the pathes to css a.s.o. are still correct and the samples (I've
tested primarly the form samples) work fine.
Thanks
Ciao
- --
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)
iD8DBQFGZ7NeLNdJvZjjVZARAsX2AKCBAv0Cfd3ozvfbm3NXMlayYz39cACfbHK9
9IWF1HHz621U4j7G5+a0pbQ=
=+oWf
-----END PGP SIGNATURE-----
Re: [jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
>
> 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?
getContextPath returns the path where the webapp is mounted
getServletPath returns the path-
- --
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)
iD8DBQFGZ8KTLNdJvZjjVZARAiwdAKC0KuC1xnffvn7ZcphoP5+rlcPDngCgyYBj
mbSvNTERTvZyg66tYChTS1w=
=zlT5
-----END PGP SIGNATURE-----
Re: [jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by Giacomo Pati <gi...@apache.org>.
-----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-----
Re: [jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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.
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
Re: [jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
>
> 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.
PS: Sorry for the previous mail which was sent by incidentally hitting the send button
- --
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)
iD8DBQFGZ8PILNdJvZjjVZARAmt3AJ9dInsgj4iL/9pGZ/cRw3EhjpbQlwCgxspe
EttHaimK7DP9MYqIj+5Qn30=
=unra
-----END PGP SIGNATURE-----
Re: [jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by Grzegorz Kossakowski <gk...@apache.org>.
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.
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?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: [jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Giacomo Pati pisze:
>>
>> Isn't HttpServletRequest.getServletPath() the one that should give you
>> what you are seeking for?
>
> 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.
>
> That's not what we need.
>
- --
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)
iD8DBQFGZ7/iLNdJvZjjVZARAm7wAKDYVXOtYClfbOXX2sOyB5oGKijZKgCgtf1S
IWzx6xgJMCWt7EhEl+vsDQQ=
=55i5
-----END PGP SIGNATURE-----
Re: [jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Giacomo Pati pisze:
>
> Isn't HttpServletRequest.getServletPath() the one that should give you what you are seeking for?
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.
That's not what we need.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: [jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502139 ]
>
> Grzegorz Kossakowski commented on COCOON-2066:
> ----------------------------------------------
>
> I have just committed the fix for this issue. Could someone test if it works correctly? Basically you need to run cocoon-webapp and check if http://localhost:8080/blocks/cocoon-forms-sample/ loads all resources correctly (especially css files).
> I would be grateful for any report.
>
> Daniel, I think that other methods of BlockCallHttpServlet[Request|Response] should also return meaningful values. It should behave just like DynamicProxyRequestHandler, right? If so, how BlockCallHttpServlet[Request|Response] can access mount path of current servlet?
Isn't HttpServletRequest.getServletPath() the one that should give you what you are seeking for?
Ciao
>
>> BlockCompletePathModule returns wrong path in scope of internal servlet call
>> ----------------------------------------------------------------------------
>>
>> Key: COCOON-2066
>> URL: https://issues.apache.org/jira/browse/COCOON-2066
>> Project: Cocoon
>> Issue Type: Bug
>> Components: - Servlet service framework
>> Affects Versions: 2.2-dev (Current SVN)
>> Reporter: Grzegorz Kossakowski
>> Assignee: Grzegorz Kossakowski
>>
>> BlockCompletePathModule uses this construct:
>> public Object getAttribute(String name, Configuration modeConf, Map objectModel) throws ConfigurationException {
>> return ObjectModelHelper.getRequest(objectModel).getContextPath() + blockPathModule.getAttribute(name, modeConf, objectModel);
>> }
>> However, when internal (service call or not) request is being made BlockCallHttpServletRequest becomes an object represnting current request but it has no meaningful representation of getContextPath method.
>> Solution to this problem might be forwarding context path value from original request.
>
- --
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)
iD8DBQFGZ61ULNdJvZjjVZARAiKWAJ91z4IA+WESAwWo113219du6btrKACgjuP6
4zrVq/3IOW4inQnEjh/FQzA=
=kk6U
-----END PGP SIGNATURE-----
[jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by "Grzegorz Kossakowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502139 ]
Grzegorz Kossakowski commented on COCOON-2066:
----------------------------------------------
I have just committed the fix for this issue. Could someone test if it works correctly? Basically you need to run cocoon-webapp and check if http://localhost:8080/blocks/cocoon-forms-sample/ loads all resources correctly (especially css files).
I would be grateful for any report.
Daniel, I think that other methods of BlockCallHttpServlet[Request|Response] should also return meaningful values. It should behave just like DynamicProxyRequestHandler, right? If so, how BlockCallHttpServlet[Request|Response] can access mount path of current servlet?
> BlockCompletePathModule returns wrong path in scope of internal servlet call
> ----------------------------------------------------------------------------
>
> Key: COCOON-2066
> URL: https://issues.apache.org/jira/browse/COCOON-2066
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Grzegorz Kossakowski
> Assignee: Grzegorz Kossakowski
>
> BlockCompletePathModule uses this construct:
> public Object getAttribute(String name, Configuration modeConf, Map objectModel) throws ConfigurationException {
> return ObjectModelHelper.getRequest(objectModel).getContextPath() + blockPathModule.getAttribute(name, modeConf, objectModel);
> }
> However, when internal (service call or not) request is being made BlockCallHttpServletRequest becomes an object represnting current request but it has no meaningful representation of getContextPath method.
> Solution to this problem might be forwarding context path value from original request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Grzegorz Kossakowski (JIRA) pisze:
> [ https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Grzegorz Kossakowski updated COCOON-2066:
> -----------------------------------------
>
> Description:
> BlockCompletePathModule uses this construct:
> public Object getAttribute(String name, Configuration modeConf, Map objectModel) throws ConfigurationException {
> return ObjectModelHelper.getRequest(objectModel).getContextPath() + blockPathModule.getAttribute(name, modeConf, objectModel);
> }
>
> However, when internal (service call or not) request is being made BlockCallHttpServletRequest becomes an object represnting current request but it has no meaningful representation of getContextPath method.
>
> Solution to this problem might be forwarding context path value from original request.
>
> was:
> BlockCompletePathModule uses this construct:
> public Object getAttribute(String name, Configuration modeConf, Map objectModel) throws ConfigurationException {
> return ObjectModelHelper.getRequest(objectModel).getContextPath() + blockPathModule.getAttribute(name, modeConf, objectModel);
> }
>
> However, when internal (service call or not) request is being made BlockCallHttpServletRequest becomes an object represnting current request but it has no meaningful representation of getContextPath method.
>
> Solution to this problem might be forwarding context path value from original request.
>
> Urgency: (was: Urgent)
>
> Thanks Daniel for your comment. I'm just working on the implementation that you described and came across some inconsistency.
>
> In CallFrameHelper class setRequest method expects that its is a HttpServletRequest but in PathDispatcher we have to deal with ServletRequest (a super interface to the first one mentioned). Am I right that CallFrameHelper should be changed so it accepts ServletRequest parameter?
>
Gosh! It's again a Mylar's fault. Ok, it's clear that Eclipse cannot be used for issue management up to now. I'll have to wait until Mylar
2.0 is polished, unfortunately...
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
[jira] Updated: (COCOON-2066) BlockCompletePathModule returns wrong
path in scope of internal servlet call
Posted by "Grzegorz Kossakowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Grzegorz Kossakowski updated COCOON-2066:
-----------------------------------------
Description:
BlockCompletePathModule uses this construct:
public Object getAttribute(String name, Configuration modeConf, Map objectModel) throws ConfigurationException {
return ObjectModelHelper.getRequest(objectModel).getContextPath() + blockPathModule.getAttribute(name, modeConf, objectModel);
}
However, when internal (service call or not) request is being made BlockCallHttpServletRequest becomes an object represnting current request but it has no meaningful representation of getContextPath method.
Solution to this problem might be forwarding context path value from original request.
was:
BlockCompletePathModule uses this construct:
public Object getAttribute(String name, Configuration modeConf, Map objectModel) throws ConfigurationException {
return ObjectModelHelper.getRequest(objectModel).getContextPath() + blockPathModule.getAttribute(name, modeConf, objectModel);
}
However, when internal (service call or not) request is being made BlockCallHttpServletRequest becomes an object represnting current request but it has no meaningful representation of getContextPath method.
Solution to this problem might be forwarding context path value from original request.
Urgency: (was: Urgent)
Thanks Daniel for your comment. I'm just working on the implementation that you described and came across some inconsistency.
In CallFrameHelper class setRequest method expects that its is a HttpServletRequest but in PathDispatcher we have to deal with ServletRequest (a super interface to the first one mentioned). Am I right that CallFrameHelper should be changed so it accepts ServletRequest parameter?
> BlockCompletePathModule returns wrong path in scope of internal servlet call
> ----------------------------------------------------------------------------
>
> Key: COCOON-2066
> URL: https://issues.apache.org/jira/browse/COCOON-2066
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Grzegorz Kossakowski
> Assignee: Grzegorz Kossakowski
>
> BlockCompletePathModule uses this construct:
> public Object getAttribute(String name, Configuration modeConf, Map objectModel) throws ConfigurationException {
> return ObjectModelHelper.getRequest(objectModel).getContextPath() + blockPathModule.getAttribute(name, modeConf, objectModel);
> }
> However, when internal (service call or not) request is being made BlockCallHttpServletRequest becomes an object represnting current request but it has no meaningful representation of getContextPath method.
> Solution to this problem might be forwarding context path value from original request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by "Grzegorz Kossakowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498410 ]
Grzegorz Kossakowski commented on COCOON-2066:
----------------------------------------------
I'm not sure how to fix it. Options we have:
1. Pass original (of the caller) request object to the BlockCallHttpServletRequest can grab values it needs. It introduces dependencies on cocoon's core functionality in servlet-service-impl so essentialy it's not an option. We don't want such dependencies.
2. Pass only needed values grabed from original request object. It does not introduce new dependencies but still we have bother ServletConnection and ServletSource classes with this implementation detail. Seems not a good idea.
3. ??? (some more clever method?)
I would be grateful for any opinions. Daniel, could you comment?
> BlockCompletePathModule returns wrong path in scope of internal servlet call
> ----------------------------------------------------------------------------
>
> Key: COCOON-2066
> URL: https://issues.apache.org/jira/browse/COCOON-2066
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Grzegorz Kossakowski
>
> BlockCompletePathModule uses this construct:
> public Object getAttribute(String name, Configuration modeConf, Map objectModel) throws ConfigurationException {
> return ObjectModelHelper.getRequest(objectModel).getContextPath() + blockPathModule.getAttribute(name, modeConf, objectModel);
> }
> However, when internal (service call or not) request is being made BlockCallHttpServletRequest becomes an object represnting current request but it has no meaningful representation of getContextPath method.
> Solution to this problem might be forwarding context path value from original request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2066) BlockCompletePathModule returns wrong
path in scope of internal servlet call
Posted by "Grzegorz Kossakowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Grzegorz Kossakowski closed COCOON-2066.
----------------------------------------
Resolution: Fixed
Fix Version/s: 2.2-dev (Current SVN)
Everything works as expected. Closing the issue.
> BlockCompletePathModule returns wrong path in scope of internal servlet call
> ----------------------------------------------------------------------------
>
> Key: COCOON-2066
> URL: https://issues.apache.org/jira/browse/COCOON-2066
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Grzegorz Kossakowski
> Assignee: Grzegorz Kossakowski
> Fix For: 2.2-dev (Current SVN)
>
>
> BlockCompletePathModule uses this construct:
> public Object getAttribute(String name, Configuration modeConf, Map objectModel) throws ConfigurationException {
> return ObjectModelHelper.getRequest(objectModel).getContextPath() + blockPathModule.getAttribute(name, modeConf, objectModel);
> }
> However, when internal (service call or not) request is being made BlockCallHttpServletRequest becomes an object represnting current request but it has no meaningful representation of getContextPath method.
> Solution to this problem might be forwarding context path value from original request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by "Daniel Fagerstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502127 ]
Daniel Fagerstrom commented on COCOON-2066:
-------------------------------------------
Great that you are working on it.
Considering the setRequest method I think it makes sense to use HttpServletRequest as neither Cocoon nor any other conceivable servlet based webapp will have any use for requests that only implement ServletRequest (which among many other things lacks context and servlet paths). So IMO it is better to down cast to the arguments to the forward method and fail as fast as possible in the unlikely situation that the arguments doesn't implement HttpServlet[Request|Response].
> BlockCompletePathModule returns wrong path in scope of internal servlet call
> ----------------------------------------------------------------------------
>
> Key: COCOON-2066
> URL: https://issues.apache.org/jira/browse/COCOON-2066
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Grzegorz Kossakowski
> Assignee: Grzegorz Kossakowski
>
> BlockCompletePathModule uses this construct:
> public Object getAttribute(String name, Configuration modeConf, Map objectModel) throws ConfigurationException {
> return ObjectModelHelper.getRequest(objectModel).getContextPath() + blockPathModule.getAttribute(name, modeConf, objectModel);
> }
> However, when internal (service call or not) request is being made BlockCallHttpServletRequest becomes an object represnting current request but it has no meaningful representation of getContextPath method.
> Solution to this problem might be forwarding context path value from original request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by "Daniel Fagerstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502071 ]
Daniel Fagerstrom commented on COCOON-2066:
-------------------------------------------
The solution that I have in mind is based on always having the current Sevlet(Service)Context, HttpServletRequest and HttpServletResponse available in the callstack. Then all the needed context and servlet paths are available when constructing the request and response objects for the internal call.
In more detail it could be implemented the following way:
* The o.a.c.callstack and o.a.c.callstack.environment (in cocoon-sevlet-service-impl) are allready implemented so that the call stack can contain request and response objects besides the context object. Take a look at the CallFrameHelper. Actually the whole thing is design so that it implements a special call stack Spring scope so that the objects on the call stack is available with dependecy injection. The later part doesn't work completetly yet, so just use the CallFrameHelper for the moment.
* The ServletConnection gets the current request (and possibly response) object from the call stack and uses these in the construction of more correct BlockCallHttpServlet[Request|Response] objects. One possibility is to let the new request/response objects wrap the current ones. An even better (although more complicated) possibility is to wrap the current request/reponse objects with dynamic proxies. By doing that extensions in the incomming request/response objects, like e.g. SAX awareness, are preserved for the sub calls.
* The newly created request/response object are used in the forward method of a dispatcher from the ServletServiceContext. Within the forward method the CallStackHelper.enterServlet methods are used for pushing the new ServletServiceContext on the call stack. These methods need to be extended so that the forward method can push the new request and response objects as well.
* With the above mechanism in place the current request, response and context objects are always avaliable att the call stack. So now the BlockCompletePathModule can get the current (and correct) request object from the call stack and get the needed context path.
> BlockCompletePathModule returns wrong path in scope of internal servlet call
> ----------------------------------------------------------------------------
>
> Key: COCOON-2066
> URL: https://issues.apache.org/jira/browse/COCOON-2066
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Grzegorz Kossakowski
>
> BlockCompletePathModule uses this construct:
> public Object getAttribute(String name, Configuration modeConf, Map objectModel) throws ConfigurationException {
> return ObjectModelHelper.getRequest(objectModel).getContextPath() + blockPathModule.getAttribute(name, modeConf, objectModel);
> }
> However, when internal (service call or not) request is being made BlockCallHttpServletRequest becomes an object represnting current request but it has no meaningful representation of getContextPath method.
> Solution to this problem might be forwarding context path value from original request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2066) BlockCompletePathModule returns
wrong path in scope of internal servlet call
Posted by "Grzegorz Kossakowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Grzegorz Kossakowski reassigned COCOON-2066:
--------------------------------------------
Assignee: Grzegorz Kossakowski
> BlockCompletePathModule returns wrong path in scope of internal servlet call
> ----------------------------------------------------------------------------
>
> Key: COCOON-2066
> URL: https://issues.apache.org/jira/browse/COCOON-2066
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Grzegorz Kossakowski
> Assignee: Grzegorz Kossakowski
>
> BlockCompletePathModule uses this construct:
> public Object getAttribute(String name, Configuration modeConf, Map objectModel) throws ConfigurationException {
> return ObjectModelHelper.getRequest(objectModel).getContextPath() + blockPathModule.getAttribute(name, modeConf, objectModel);
> }
> However, when internal (service call or not) request is being made BlockCallHttpServletRequest becomes an object represnting current request but it has no meaningful representation of getContextPath method.
> Solution to this problem might be forwarding context path value from original request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2066) BlockCompletePathModule returns wrong
path in scope of internal servlet call
Posted by "Rice Yeh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rice Yeh updated COCOON-2066:
-----------------------------
Attachment: cocoon-servlet-service-impl.patch
Attached is a patch for BlockCallHttpServletRequest. The implementation is based on the understanding in http://www.mail-archive.com/dev@cocoon.apache.org/msg52250.html
Attributes handling for http session is not implemented in this patch yet because I have not figured out how to implement it.
Rice
> BlockCompletePathModule returns wrong path in scope of internal servlet call
> ----------------------------------------------------------------------------
>
> Key: COCOON-2066
> URL: https://issues.apache.org/jira/browse/COCOON-2066
> Project: Cocoon
> Issue Type: Bug
> Components: - Servlet service framework
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Grzegorz Kossakowski
> Assignee: Grzegorz Kossakowski
> Fix For: 2.2-dev (Current SVN)
>
> Attachments: cocoon-servlet-service-impl.patch
>
>
> BlockCompletePathModule uses this construct:
> public Object getAttribute(String name, Configuration modeConf, Map objectModel) throws ConfigurationException {
> return ObjectModelHelper.getRequest(objectModel).getContextPath() + blockPathModule.getAttribute(name, modeConf, objectModel);
> }
> However, when internal (service call or not) request is being made BlockCallHttpServletRequest becomes an object represnting current request but it has no meaningful representation of getContextPath method.
> Solution to this problem might be forwarding context path value from original request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.