myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Freedman (JIRA)" <...@myfaces.apache.org>
Subject [jira] Resolved: (PORTLETBRIDGE-179) Portlet Bridge 3.0.0 -- Mojarra 2.0 contains some FacesContext attributed that expect to be held for a full lifecycle
Date Tue, 08 Feb 2011 17:50:58 GMT

     [ https://issues.apache.org/jira/browse/PORTLETBRIDGE-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Freedman resolved PORTLETBRIDGE-179.
--------------------------------------------

       Resolution: Fixed
    Fix Version/s: 3.0.0-alpha

Modfied code so you can configure the portlet via an init parameter with a specific set of
FacesContext attributes that should be carried from the action to the render.  For these samples
I configure with the two attributes needed to get the Facelets (render) restore to work properly.

> 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
>          Components: Impl
>    Affects Versions: 3.0.0-alpha
>            Reporter: Michael Freedman
>            Assignee: Michael Freedman
>             Fix For: 3.0.0-alpha
>
>
> 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

        

Mime
View raw message