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