[jira] Commented: (MYFACES-660) (Patch provided) "request scoping" from Portlet Action- to RenderRequest should not occur via Attribute Request Map

["Wendy Smoak (JIRA)" <de...@myfaces.apache.org>]

    [ 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