[ http://issues.apache.org/jira/browse/MYFACES-821?page=comments#action_12361210 ]
Michael Lipp commented on MYFACES-821: -------------------------------------- Mmh, the problem is that I have looked into this more than a month ago, and as a lot has happened since, it is a bit hard to remember the details. I'm afraid, all I can do just now is point you to my code at http://cvs.sourceforge.net/viewcvs.py/wfmopen/wfmopen/src/de/danet/an/util/jsf/MyFacesAdaptedPortlet.java?rev=1.13&view=log As far as the view-id is concerned: I have assumed that the view-id is a unique id for JSF model instances. If the view-id isn't, something else must be... Regards, Michael > Usage of request attributes for caching > --------------------------------------- > > Key: MYFACES-821 > URL: http://issues.apache.org/jira/browse/MYFACES-821 > Project: MyFaces > Type: Bug > Versions: 1.1.0 > Environment: liferay 3.6.1 > Reporter: Michael Lipp > > 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
