[ http://issues.apache.org/jira/browse/MYFACES-821?page=comments#action_12365439 ]
Stan Silvert commented on MYFACES-821: -------------------------------------- Hi Michael, I understand what you are saying. You are correct that the spec does allow LifeRay some wiggle room in this regard. LifeRay complies with the letter of the spec, but not its spirit. As I stated before, a portlet should be a self-contained unit. The fact that LifeRay allows request attributes to "leak" into another portlet tells me that LifeRay is doing something wrong - even though they have technically followed the letter of the spec. Even if we fixed this in MyFaces, there is no assurance that another portlet will not cause the same kind of name collision on its own. What you are saying is that if I put two portlets on a page then I have to know every request attribute that might be set in each portlet. Then I must manually check for name collisions. That doesn't make any sense at all. I might not even have the portlet source code. I only know the behavior of three containers in regard to this issue. They are JBoss Portal, LifeRay, and Pluto. Of the three, LifeRay is the only one that exhibits the problem. The fact that Pluto does make sure that request attributes scoped, bolsters my argument because Pluto is the reference implementation. The real solution to this problem is to get a ruling from the portlet expert group. I will try to get an official statement out of them. Stan > 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
