[ http://issues.apache.org/jira/browse/MYFACES-821?page=comments#action_12365442 ]
Michael Lipp commented on MYFACES-821: -------------------------------------- The approach to get a ruling from the expert group is OK. It gives us (the users) something to show to Liferay support. Pluto being the reference implementation and providing scoping does not really help. Even a reference implementation may go beyond the minimum requirements and provide features that MAY be implemented. Of course, any portlet that does not observe the specs is a thread. But because the spec is as it is, I do program all my portlets in such a way that they can handle the situation that the spec implies -- though I don't like the burden imposed on me by the spec. What I still do not really understand is why it should be so difficult to prevent the name collition in the MyFaces bridge. A simple unique id of the JSF model instance is sufficient. But this is only an issue if the expert group does not support your point of view. I'm really curious about the expert group's statement. 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 > 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
