[PORTLETBRIDGE-179] Portlet Bridge 3.0.0 -- Mojarra 2.0 contains some FacesContext attributed that expect to be held for a full lifecycle

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0.0-alpha
• Fix Version/s: 3.0.0-alpha
• Component/s: Impl
• Assignee: Michael Freedman
• Reporter: Michael Freedman
• Created: 03/Feb/11 22:20
• Updated: 08/Feb/11 17:50
• Resolved: 08/Feb/11 17:50

Description

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.