Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <8851983.1181160626324.JavaMail.jira@brutus>
Date: Wed, 6 Jun 2007 13:10:26 -0700 (PDT)
From: "Daniel Fagerstrom (JIRA)" <jira@apache.org>
To: dev@cocoon.apache.org
Subject: [jira] Commented: (COCOON-2066) BlockCompletePathModule returns
 wrong path in scope of internal servlet call
In-Reply-To: <24988313.1179925096153.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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