[ http://issues.apache.org/jira/browse/MYFACES-821?page=all ]
Mike Kienenberger updated MYFACES-821:
--------------------------------------
Status: Open (was: Patch Available)
> Usage of request attributes for caching
> ---------------------------------------
>
> Key: MYFACES-821
> URL: http://issues.apache.org/jira/browse/MYFACES-821
> Project: MyFaces Core
> Type: Bug
> Versions: 1.1.0
> Environment: liferay 3.6.1
> Reporter: Michael Lipp
> Assignee: Stan Silvert
>
> JspStateManagerImpl (and maybe other classes) uses request attributes for
> caching state. This causes a wrong view to be used if there is more than one
> JSF-based portlet on a single page. MyFaces saves the serialized view of the
> first portlet on the page as a request attribute. To avoid re-serialization,
> MyFaces subsequently checks if there already is a request attribute with a
> serialized view. As request attributes are not scoped to a single portlet
> (the portlet specification does not require this), the serialized view of the
> first portlet will be found and used by the second portlet.
> This usage of request attributes may also be the cause of MYFACES-549.
> As JSF, of course, does not need to know about the portlet environment, it
> cannot be required that MyFaces saves such information "per view", e.g. by
> prepending the viewId to the key for the request attribute (although this
> would solve the problem). IMHO any request attributes added during
> lifecycle.render() should be removed after lifecycle() render by the portlet
> bridge. (The same applies to request attributes added during
> lifecycle.execute(), but these should also be re-added before
> lifecycle.render().) I have implemented this in my portlet bridge as a
> workaround.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
