You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Tanju Erinmez (JIRA)" <my...@incubator.apache.org> on 2005/10/03 20:00:59 UTC
[jira] Created: (MYFACES-660) (Patch provided) "request scoping" from Portlet Action- to RenderRequest should not occur via Attribute Request Map
(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
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
[jira] Commented: (MYFACES-660) (Patch provided) "request scoping"
from Portlet Action- to RenderRequest should not occur via Attribute
Request Map
Posted by "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
[jira] Commented: (MYFACES-660) (Patch provided) "request scoping"
from Portlet Action- to RenderRequest should not occur via Attribute
Request Map
Posted by "Stan Silvert (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-660?page=comments#action_12451434 ]
Stan Silvert commented on MYFACES-660:
--------------------------------------
After attending the JSR-301 meeting and talking this issue over with some portlet experts, I think I know what needs to be done.
The only thing that needs to be fixed is propagation of request attributes from processAction to facesRender. Attributes are saved at the end of processAction. The saved attributes are kept until the next processAction or until the session times out/invalidates. On each facesRender, request attributes set during processAction are restored just before lifecycle.render().
In short, managed beans with request scope should now work across all portlet containers. It's only taken 13 months to get this resolved. Better late than never!
> (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 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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-660) (Patch provided) "request scoping" from Portlet Action- to RenderRequest should not occur via Attribute Request Map
Posted by "Stan Silvert (JIRA)" <my...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-660?page=comments#action_12331407 ]
Stan Silvert commented on MYFACES-660:
--------------------------------------
I tried your demo app on JBoss Portal and it works as designed. The counter updates each time each portlet is refreshed. As for NumberBean, you have this code:
public class NumberBean implements Serializable {
private static int count = 0;
private int value = ++count;
public void setValue(int value) {
this.value = value;
}
public int getValue() {
return value;
}
}
So, each time the component tree is rebuilt, the count will increment. We had a discussion about rebuilding the component tree too often in portlets because it could be a performance issue. However, the JSF spec suggests that it be done that way for portlets and we haven't had time to figure out an acceptable optimization.
> (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
[jira] Commented: (MYFACES-660) (Patch provided) "request scoping" from Portlet Action- to RenderRequest should not occur via Attribute Request Map
Posted by "Tanju Erinmez (JIRA)" <my...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-660?page=comments#action_12331430 ]
Tanju Erinmez commented on MYFACES-660:
---------------------------------------
If I understand you correctly, you tried jboss with the myfaces-impl_patch.jar, invoked the button in portlet X and you saw the same numberBean value in the same portlet X but an incrementing numberBean value in the other portlet.
If that's the case I totally agree with your explanation, the numberBean in the other portlet will be implicitly created each time because no restoreView phase would have occurred before to give t:saveState a head start.
However, if you describe the other scenario (which occurs with pluto) with myfaces_original.jar where the numberBean is incremented when an action in the same portlet is invoked, then I would conclude that this request scoped bean is not "transferred" after restoreView (in ActionRequest) to the renderResponse phase (in RenderRequest), presuming t:saveState works as expected and indifferently from servlet/portlet. And if this is expected behavior wouldn't this mean that request scoping is not supposed to work with JSF + Portlets at all?
> (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
[jira] Commented: (MYFACES-660) (Patch provided) "request scoping" from Portlet Action- to RenderRequest should not occur via Attribute Request Map
Posted by "Stan Silvert (JIRA)" <my...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-660?page=comments#action_12331522 ]
Stan Silvert commented on MYFACES-660:
--------------------------------------
It is the second case. I used plain MyFaces 1.1.0.
What I think we are seeing is that t:saveState does not behave as "expected" in a portlet environment.
Request scoping works fine in JBoss Portal and Pluto as far as I know. However, because of the errata you cited, I'm not sure that will always be the case.
> (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
[jira] Commented: (MYFACES-660) (Patch provided) "request scoping" from Portlet Action- to RenderRequest should not occur via Attribute Request Map
Posted by "Stan Silvert (JIRA)" <my...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-660?page=comments#action_12331208 ]
Stan Silvert commented on MYFACES-660:
--------------------------------------
We should fix this as per the JSR-168 errata. However, we should not make the changes described in MYFACES-549 unless required to do so by a change to the portlet spec.
The expert group has decided to clarify the fact that attributes should not be shared between action and render requests in the same portlet. It is unthinkable that they would turn 180 degrees and say that attributes should be shared by different portlets.
After looking at this a bit, I think the rabbit hole might be pretty deep.
Tanju, can you help me out by providing simple test case? I want to fully understand the problem before we apply a patch. I am ready to test a fix on Pluto and JBoss if you are ready for Liferay and BEA.
> (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
> Attachments: myfaces-impl-src-java.diff
>
> 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
[jira] Updated: (MYFACES-660) (Patch provided) "request scoping" from Portlet Action- to RenderRequest should not occur via Attribute Request Map
Posted by "Tanju Erinmez (JIRA)" <my...@incubator.apache.org>.
[ 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
[jira] Commented: (MYFACES-660) (Patch provided) "request scoping" from Portlet Action- to RenderRequest should not occur via Attribute Request Map
Posted by "Tanju Erinmez (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-660?page=comments#action_12356340 ]
Tanju Erinmez commented on MYFACES-660:
---------------------------------------
Apologies for the absence (I was on long vacation)
Thanks for your input, I'll have a closer look to figure out the saveState differences.
Unfortunately, I was not able to "simply" start up a BEA based portal with the portlet example. Due to "profound" library version conflicts, my status as BEA novice, and my satisfaction with the jboss/tomcat platform I would prefer not to hunt down this problem at this moment.
> (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
[jira] Updated: (MYFACES-660) (Patch provided) "request scoping" from Portlet Action- to RenderRequest should not occur via Attribute Request Map
Posted by "Tanju Erinmez (JIRA)" <my...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-660?page=all ]
Tanju Erinmez updated MYFACES-660:
----------------------------------
Attachment: myfaces-impl-src-java.diff
Minimal invasive patch for :
PortletExternalContextImpl.java
RequestMap.java
MyFacesGenericPortlet.java
(not mixed with patch from MYFACES-650)
> (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
> Attachments: myfaces-impl-src-java.diff
>
> 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
[jira] Resolved: (MYFACES-660) (Patch provided) "request scoping"
from Portlet Action- to RenderRequest should not occur via Attribute
Request Map
Posted by "Stan Silvert (JIRA)" <de...@myfaces.apache.org>.
[ http://issues.apache.org/jira/browse/MYFACES-660?page=all ]
Stan Silvert resolved MYFACES-660.
----------------------------------
Fix Version/s: 1.1.5-SNAPSHOT
Resolution: Fixed
> (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 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: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira