[ http://issues.apache.org/jira/browse/MYFACES-660?page=all ]
Tanju Erinmez updated MYFACES-660:
----------------------------------
Attachment: navdemo2.war
Thanks for looking into this, Stan!
Please find the demo attached. I rebuild the example again and verified the
behavior from my comment before. An original (myfaces-impl_original.jar) is
also packaged for quick behavior comparison. patched and original jars are
based on rev. 292564.
I agree this shouldn't be fixed the way the fix for MYFACES-549 works. The one
that's included with this issue does it more generally.
I will be gladly available for testing, however, I should have been more
specific: I have only tested it with Liferay 3.6.1 & Pluto 1.0.1-rc4 (I
basically took over the BEA story from Brian :-)
-> I'll look for a non-commercial BEA license and set that stuff up. Quoting
another JBOSSer, this should be trivial... :-)
> (Patch provided) "request scoping" from Portlet Action- to RenderRequest
> should not occur via Attribute Request Map
> -------------------------------------------------------------------------------------------------------------------
>
> Key: MYFACES-660
> URL: http://issues.apache.org/jira/browse/MYFACES-660
> Project: MyFaces
> Type: Bug
> Components: Implementation
> Versions: Nightly
> 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
> Assignee: Stan Silvert
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
