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] Created: (JS2-987) Portal request parameterMap must be captured before invoking a portlet on WebSphere
Date Tue, 05 May 2009 14:30:31 GMT
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

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

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