[
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: [email protected]
For additional commands, e-mail: [email protected]
