[ https://issues.apache.org/jira/browse/MYFACES-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463454 ]
Wendy Smoak commented on MYFACES-660: ------------------------------------- http://svn.apache.org/viewvc?view=rev&rev=477350 > (Patch provided) "request scoping" from Portlet Action- to RenderRequest > should not occur via Attribute Request Map > ------------------------------------------------------------------------------------------------------------------- > > Key: MYFACES-660 > URL: https://issues.apache.org/jira/browse/MYFACES-660 > Project: MyFaces Core > Issue Type: Bug > Components: Portlet_Support > Affects Versions: 1.1.2-SNAPSHOT > Environment: myfaces-api + myfaces-impl (rev. 292564) , > pluto-1.0.1-rc4 (binary bundle), Liferay 3.6.1 Enterprise, jdk1.5.0_03-b07 > Reporter: Tanju Erinmez > Assigned To: Stan Silvert > Fix For: 1.1.5-SNAPSHOT > > Attachments: myfaces-impl-src-java.diff, navdemo2.war > > > Hi, > After pulling my hair out (and getting a transplant :) I think there is a > refined spec vs. current implementation clash [1]. I have looked into this > and come up with a possible solution [2]. After having also discussed > MYFACES-549 with Brian Chan from Liferay [3] I think you can hit two birds > with one stone with the provided patch and get Liferay & BEA platform support > for free ;-)). > Cheers, > Tanju > 1. Details > -------------- > There has been a refinement to the JSR 168 Spec PLT.11.1.3 recently which now > clearly indicates that it cannot be assumed that attributes from an > ActionRequest will be available in a RenderRequest (see > http://jcp.org/aboutJava/communityprocess/maintenance/jsr168/Portlet1.0-ERRATA.html#issue10). > On the other hand, it is a legitimate need for JSF to carry over results > (e.g. Request scoped managed beans) from the lifecycle execution part > (ActionRequest) over to the render part (RenderRequest). > AFAIK, there is no special treatment of this case, which means JSF just > populates and fetches from the attribute map assuming a standard servlet > request behavior. > Instead of interfering with this already for servlet mode working behavior I > have come up with a special Request Map treatment approach. However, I'm not > sure which of the following processing model the design of the portlet > integration follows and would be glad if some light could be shed on this: > 1. Portlet X receives an ActionRequest and later a RenderRequest this two > Requests make up the entire faces lifecycle. Portlet Y from the same > PortletContext just receives an ordinary RenderRequest without knowing of any > previous ActionRequests > 2. Same as above but Portlet Y is "aware" of the ActionRequest e.g. somehow > Interportlet communication shall be achieved in the future > 2. Solution > ----------------- > After rolling the dice, I have decided to go with the first approach. The > idea is to use a separate map stored in the PortletSession to mimic a request > map which spans over two requests (Action & RenderRequest). This map is > removed from the PortletSession after the render cycle is concluded. > I have tested this approach with two simple portlets each containing 3 jsp > pages embedding a t:saveState binding to the same managed request scoped > bean. I could verify on pluto as well as Liferay that this bean was created > only once and its value is preserved despite changing pages in the same > portlet. (I merely used saveState as a lazy way to check for request > leaking -> it will not work for multiple portlet with the intention to have > several "conversations" in parallel). > However, what puzzles me right now is that without the patch the "standard" > behavior on pluto is that the bean is created everytime. This indicates that > the ActionRequest attribute map is not inherited to the RenderRequest (is ok > according to PLT.11.1.3) which would actually mean that request scoped beans > haven' worked up to now which I cannot believe. So this is speculative as I > have not verified this yet. > 3. Liferay et al. > -------------------- > MYFACES-549 is somewhat different to the case above because it revolves > around the problem that the attribute map from one RenderRequests is visible > to another RenderRequests (also governed by PLT.11.1.3) > I have had a very brief discussion with Brian Chan from Liferay (see > http://support.liferay.com/browse/LEP-287) and apparently it's not only them > who interpret PLT.11.1.3 differently but also BEA. They don't see it as a > "must" to confine the attribute maps to the respective request but rather > inherit it accross subsequent requests. I have asked Brian to take this issue > to the 168 EG and get another errata out whether strict isolation is required > or inheritance permitted. > I think for myfaces to run on Liferay & presumably BEA in the forseable > future :) it is important to clean up the attribute map of the RenderRequest > one way or the other so that it is not seen by the subsequent RenderRequest > of a different portlet. > -> This is implemented in the patch as well :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira