cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: [jira] Updated: (COCOON-2066) BlockCompletePathModule returns wrong path in scope of internal servlet call
Date Wed, 06 Jun 2007 21:34:25 GMT
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/

Mime
View raw message