[jira] Commented: (MYFACES-821) Usage of request attributes for caching

["Tanju Erinmez (JIRA)" <de...@myfaces.apache.org>]

    [ http://issues.apache.org/jira/browse/MYFACES-821?page=comments#action_12373736 ] 

Tanju Erinmez commented on MYFACES-821:
---------------------------------------

Greetings,

Just wanted to let you know that things have moved again and this particular problem (which has haunted me, too in MYFACES-660) is supposed to be resolved in the newest Liferay 4.0.0 version. (see also http://support.liferay.com/browse/LEP-287 ).

Resolution (though have not tried), is mention at http://www.theserverside.com/news/thread.tss?thread_id=39830#205741 and consists of setting the following parameters accordingly in your liferay-portlet.xml:

use-portal-class-loader
private-request-attributes

Enjoy,
Tanju 

> Usage of request attributes for caching
> ---------------------------------------
>
>          Key: MYFACES-821
>          URL: http://issues.apache.org/jira/browse/MYFACES-821
>      Project: MyFaces Core
>         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