Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 13970 invoked from network); 6 Jun 2007 21:34:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Jun 2007 21:34:54 -0000 Received: (qmail 90721 invoked by uid 500); 6 Jun 2007 21:34:55 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 90675 invoked by uid 500); 6 Jun 2007 21:34:55 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 90664 invoked by uid 99); 6 Jun 2007 21:34:55 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jun 2007 14:34:55 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [216.86.168.178] (HELO mxout-03.mxes.net) (216.86.168.178) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jun 2007 14:34:50 -0700 Received: from [192.168.1.4] (unknown [87.206.142.101]) by smtp.mxes.net (Postfix) with ESMTP id 244D751931 for ; Wed, 6 Jun 2007 17:34:28 -0400 (EDT) Message-ID: <46672861.7060803@apache.org> Date: Wed, 06 Jun 2007 23:34:25 +0200 From: Grzegorz Kossakowski User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [jira] Updated: (COCOON-2066) BlockCompletePathModule returns wrong path in scope of internal servlet call References: <7105931.1181165426181.JavaMail.jira@brutus> In-Reply-To: <7105931.1181165426181.JavaMail.jira@brutus> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on 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/