[ http://issues.apache.org/jira/browse/MYFACES-821?page=comments#action_12365358 ]
Stan Silvert commented on MYFACES-821: -------------------------------------- I contend that the spec actually does at least imply that request attributes are scoped to a single portlet. To do otherwise breaks the whole idea that a portlet is a single application unit with its own environment. The relevant section of the spec is PLT 11.4. Also, this part of the spec has been clarified by the expert group here: http://www.jcp.org/aboutJava/communityprocess/maintenance/jsr168/Portlet1.0-ERRATA.html#issue10 Even this is not quite clear enough and it should be further clarified by the portlet EG. As of now, I see no reason to change anything in MyFaces for this. I know of at least two Portlet containers that take care of the scoping already. Surely it would not be that hard for LifeRay to do so as well. > 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
