[
https://issues.apache.org/jira/browse/COCOON-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502139
]
Grzegorz Kossakowski commented on COCOON-2066:
----------------------------------------------
I have just committed the fix for this issue. Could someone test if it works
correctly? Basically you need to run cocoon-webapp and check if
http://localhost:8080/blocks/cocoon-forms-sample/ loads all resources correctly
(especially css files).
I would be grateful for any report.
Daniel, I think that other methods of BlockCallHttpServlet[Request|Response]
should also return meaningful values. It should behave just like
DynamicProxyRequestHandler, right? If so, how
BlockCallHttpServlet[Request|Response] can access mount path of current servlet?
> 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
> Assignee: 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.
