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/05 16:30:31 UTC
[jira] Created: (JS2-987) Portal request parameterMap must be
captured before invoking a portlet on WebSphere
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 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
[jira] Updated: (JS2-987) Portal request parameterMap must be
captured before invoking a portlet on WebSphere
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/JS2-987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma updated JS2-987:
--------------------------
Attachment: JS2-987.patch
> 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
[jira] Resolved: (JS2-987) Portal request parameterMap must be
captured before invoking a portlet on WebSphere
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ 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