Major Description
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.