myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blake Sullivan <>
Subject Re: [jira] [Created] (PORTLETBRIDGE-221) Add explicit exclusions for trinidad in 329 branch
Date Thu, 20 Oct 2011 21:27:32 GMT
On 10/20/11 2:13 PM, Michael Freedman (Created) (JIRA) wrote:
> Add explicit exclusions for trinidad in 329 branch
> ---------------------------------------------------
>                   Key: PORTLETBRIDGE-221
>                   URL:
>               Project: MyFaces Portlet Bridge
>            Issue Type: Bug
>            Components: Impl
>      Affects Versions: 2.0.0
>              Reporter: Michael Freedman
>              Assignee: Michael Freedman
> We are running into problems with a user of the 329 branch codeline when using with extra
Faces (componentkit) extensions.  The problem is the bridge is updating the bridge scope at
the end of the render request pushing all new attributes created during the render into the
scope.  These extensions are expecting this so numerous request scope attrs which are "flags"
that something is initialized/done are inappropriately being carried forward and used causing
malfunctions.  At the moment we don't want to just blanket reverse the code from saving the
scope at the end of the render -- instead deciding the safest thing is to just exclude the
specific packages that might exist.
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
> For more information on JIRA, see:
I don't know why we wouldn't blanket reverse this change made in 
PORTLEETBRIDGE-221.  The current bridge behavior is causing 
request-scoped attributes to live longer than a request.  This appears 
to violate the spirit of section 5.1.2 of the bridge specification:

"Specifically, the bridge must implement a notion of a bridge request 
scope that supplies the expected Faces semantics."

And the letter of the specification:

"Upon completion of each portlet render, do not preserve any changes in 
the request scope back into the bridge request scope except those 
related to internal bridge operations (e.g. VIEW_STATE_PARAM 
management).  In the portlet (and Faces) model, render is supposed to be 

-- Blake Sullivan

View raw message