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 2010/10/16 04:16:35 UTC
[jira] Updated: (JS2-1222) Nested Portlet servlet include dispatch
is failing for a ResourceRequest on Websphere 6.1.0.23 when targeting a
filter (like Wicket)
[ https://issues.apache.org/jira/browse/JS2-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma updated JS2-1222:
---------------------------
Description:
The problem is caused by incorrect order of retrieving a request attribute within a Portlet dispatched servlet.
First the PortletRequest (cached) attributes needs to be evaluated before delegating to the web container.
This is needed as the web container itself might have already set the attribute value before which *only* is stored in the PortletRequest attribute cache (within the PortletWindow).
In particular this failed when using a ResourceRequest which is from the portal *forwarded* to the portlet.
If that portlet subsequently dispatched again using an *include*, Websphere still saw the initial dispatcher type (forward) instead of the current type (include), causing it to fail finding the appropriate filter.
Fixing this required changes to both the pluto-container (see: PLUTO-598) as well as the jetspeed-portal artifacts.
Affects Version/s: 2.2.1
Fix Version/s: 2.2.2
Summary: Nested Portlet servlet include dispatch is failing for a ResourceRequest on Websphere 6.1.0.23 when targeting a filter (like Wicket) (was: Portal Site manager is not working on Websphere 6.1.0.23)
> Nested Portlet servlet include dispatch is failing for a ResourceRequest on Websphere 6.1.0.23 when targeting a filter (like Wicket)
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JS2-1222
> URL: https://issues.apache.org/jira/browse/JS2-1222
> Project: Jetspeed 2
> Issue Type: Bug
> Components: Admin Portlets
> Affects Versions: 2.2.1
> Reporter: Vivek Kumar
> Assignee: Ate Douma
> Fix For: 2.2.2
>
>
> The problem is caused by incorrect order of retrieving a request attribute within a Portlet dispatched servlet.
> First the PortletRequest (cached) attributes needs to be evaluated before delegating to the web container.
> This is needed as the web container itself might have already set the attribute value before which *only* is stored in the PortletRequest attribute cache (within the PortletWindow).
> In particular this failed when using a ResourceRequest which is from the portal *forwarded* to the portlet.
> If that portlet subsequently dispatched again using an *include*, Websphere still saw the initial dispatcher type (forward) instead of the current type (include), causing it to fail finding the appropriate filter.
> Fixing this required changes to both the pluto-container (see: PLUTO-598) as well as the jetspeed-portal artifacts.
--
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