cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grzegorz Kossakowski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COCOON-2066) BlockCompletePathModule returns wrong path in scope of internal servlet call
Date Wed, 23 May 2007 22:25:16 GMT

    [ https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498410
] 

Grzegorz Kossakowski commented on COCOON-2066:
----------------------------------------------

I'm not sure how to fix it. Options we have:
1. Pass original (of the caller) request object to the BlockCallHttpServletRequest can grab
values it needs. It introduces dependencies on cocoon's core functionality in servlet-service-impl
so essentialy it's not an option. We don't want such dependencies.
2. Pass only needed values grabed from original request object. It does not introduce new
dependencies but still we have bother ServletConnection and ServletSource classes with this
implementation detail. Seems not a good idea.
3. ??? (some more clever method?)

I would be grateful for any opinions. Daniel, could you comment?

> 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