[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Freedman resolved PORTLETBRIDGE-10.
-------------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0
Fixed by checkin of PORTLETBRIDGE-36 : upgrade to revision 14 of the
specification.
> Bridge should restore BridgeRequest scope in render before acquiring the
> FacesContext
> -------------------------------------------------------------------------------------
>
> Key: PORTLETBRIDGE-10
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-10
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: Impl
> Affects Versions: 1.0.0-alpha-2
> Environment: Any
> Reporter: Michael Freedman
> Assignee: Michael Freedman
> Priority: Minor
> Fix For: 1.0.0, 2.0.0
>
>
> Currently the Bridge restores the bridge request scope attributes along with
> any action parameters (if requested) and the view after acquiring the
> FacesContext. As the spec says we only exclude those attributes (from
> action) that existed before calling the Bridge/Faces we should restore these
> attributes before communicating with faces during render in case any of the
> FacesContext extensions need access to these attributes.
> Note: Restoring the action parameters should not me moved. As this
> restoration involves wrapping the request we can't move it as the
> Faces/ExternalContext must be constructed with the portlet containers native
> request object. This is so externalcontext.dispatch will work in a JSR168
> world that doesn't define request wrapping.
> Note: restoring the view also must remain where it is after the FacesContext
> activation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
