Portlet Bridge 3.0.0 -- Mojarra 2.0 contains some FacesContext attributed that
expect to be held for a full lifecycle
---------------------------------------------------------------------------------------------------------------------
Key: PORTLETBRIDGE-179
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-179
Project: MyFaces Portlet Bridge
Issue Type: Bug
Reporter: Michael Freedman
Assignee: Michael Freedman
In the situation that a ViewRoot isn't being restored by Faces (i.e. the
client/bridge pushes an existing ViewRoot into the FacesContext prior to
calling restore), and the application has composite components (and hence using
Facelets), the restore/subsequent save gets all screwed up because to work
properly Faces expects a couple of FacesContext attributes to also be set at
this time.
I.e. in the bridge at the end of the action phase we release the FacesContext
-- this causes attrs to be lost. However we hold onto the ViewRoot (because we
can't Faces save it) in a in-memory cache. In the subsequent render we push
this viewRoot back into the facesContext before we call restoreView. When the
Faces view contains composite components things go off the rails (because it
expects the FacesContext to contain two attributes (one keyed with the viewRoot
object of the current view (value -- boolean = true) and another keyed with
"com.sun.faces.FACELET_FACTORY").
FYI ... I have contacted the Mojarra team to determine whether they will
consider this a bug on their side or not. However to workaround in existing
versions I should add a new portlet initParam (maybe something that can be
added to the faces-config as well -- but we will wait on the Mojarra guys
first) that allows you to name a list of attributes that should be preserved.
Then change the code to preserve and restore only those attributes that are
requested in this config.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
