portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Resolved: (JS2-987) Portal request parameterMap must be captured before invoking a portlet on WebSphere
Date Tue, 05 May 2009 22:54:30 GMT

     [ 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

View raw message