[ http://issues.apache.org/jira/browse/MYFACES-821?page=comments#action_12365405 ]
Michael Lipp commented on MYFACES-821: -------------------------------------- On the contrary! English may not be my first language, but I tend to rely on my logical thinking. JSR-168, including the errata, states that an implementor may not rely on one portlet's request attributes being available in another portlet. But this does not imply that a container MUST do scoping of attributes. It MAY do, and obviously some do it, others don't. I have pointed out a problem with MyFaces bridge running in Liferay. Like it or not, Liferay behaves according to specs (at least in this respect). If MyFaces bridge wants to be portable among all JSR-168 compliant portlet containers, this is a bug that needs to be fixed (the fix is easy and can be found in my sources, though as Martin has pointed out, the view-id is not a unique model instance, but surely there is such a thing). If MyFaces bridge is specified to support only a subset of JSR-168 compliant portlet containers, this is only a request for improvement. But then MyFaces should clearly state which JSR-168 compliant containers it is known not to support, so that others do not run into this problem. Believe me, while the fix was easy (and works well for me though it may be incomplete), it took me a long time to find the cause, so this is not a trivial issue. > 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
