myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wendy Smoak (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (MYFACES-660) (Patch provided) "request scoping" from Portlet Action- to RenderRequest should not occur via Attribute Request Map
Date Wed, 10 Jan 2007 03:40:27 GMT

    [ 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

        

Mime
View raw message