You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Ate Douma (JIRA)" <je...@portals.apache.org> on 2009/05/06 00:54:30 UTC
[jira] Resolved: (JS2-987) Portal request parameterMap must be
captured before invoking a portlet on WebSphere
[ https://issues.apache.org/jira/browse/JS2-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma resolved JS2-987.
---------------------------
Resolution: Fixed
Patch applied.
> Portal request parameterMap must be captured before invoking a portlet on WebSphere
> -----------------------------------------------------------------------------------
>
> Key: JS2-987
> URL: https://issues.apache.org/jira/browse/JS2-987
> Project: Jetspeed 2
> Issue Type: Bug
> Components: Container
> Affects Versions: 2.2.0
> Environment: Websphere 6.1
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 2.2.0
>
> Attachments: JS2-987.patch
>
>
> Websphere provides a dynamic map from request.getParameterMap() which means that its content might change when performing request dispatching using additional query string parameters.
> Within the dispatched servlet, it is therefore impossible to peek back at the state of the initial parameterMap before the dispatch.
> However, for managing and deriving the actual parameterMap to be provided to a servlet dispatched from a Portlet we depend on a stable/immutable view on this initial parameterMap.
> The current implementation, which retrieves the portal request parameterMap "on demand", e.g, possible when already within a dispatched servlet, causes JSR-286 TCK test failures on Websphere as result,
> and of course, not just that: its really providing an incorrect parameterMap to the servlet, failing to honor the spec requirements.
> I've come up with a patch (will attach in a minute for review) which solves this by capturing the portal request parameterMap upfront right after the navigational state has been determined.
> This patch I already tested against Websphere 6.1 and now all JSR-286 RequestDispatcher TCK tests pass again!
> And I've also run successfully build test cases and the full JSR-286 TCK on Tomcat with this patch.
> Furthermore, this fix solves another potential error when using multi-threaded rendering on Websphere: as WebSphere only "sees" a single (portal) request, any concurrent request dispatching for one portlet/servlet might *change*
> the current portal parameterMap as seen by other portlets, leading to an even more serious concurrency issue.
> I think the impact of this patch is very low and won't cause any side-effects but fixing the above issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org