cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Fagerstrom (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COCOON-2066) BlockCompletePathModule returns wrong path in scope of internal servlet call
Date Wed, 06 Jun 2007 20:10:26 GMT

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


Mime
View raw message