ICEfaces
  1. ICEfaces
  2. ICE-3799

standardRequestScope propagating extra attributes under Spring Web Flow 2

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8DR#1
    • Fix Version/s: 1.8DR#2, 1.8
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces

      Description


      When standardRequestScope is enabled, some values appear to be retained from previous requests.

        Activity

        Ted Goddard created issue -
        Ted Goddard made changes -
        Field Original Value New Value
        Assignee Mircea Toma [ mircea.toma ] Ted Goddard [ ted.goddard ]
        Hide
        Ted Goddard added a comment -

        This problem is confirmed specifically for Spring Web Flow and appears to have been present early in the 1.8 cycle.

        The root cause is the interaction of the Extended Request Scope lifetime and the ExternalContext.release(). SWF causes release() to be called many times during a single JSF lifecycle (since it manages the lifecycle externally) so we suppress request map clearing for SWF. Unfortunately, this means that the request map is never cleared in the case of SWF.

        Show
        Ted Goddard added a comment - This problem is confirmed specifically for Spring Web Flow and appears to have been present early in the 1.8 cycle. The root cause is the interaction of the Extended Request Scope lifetime and the ExternalContext.release(). SWF causes release() to be called many times during a single JSF lifecycle (since it manages the lifecycle externally) so we suppress request map clearing for SWF. Unfortunately, this means that the request map is never cleared in the case of SWF.
        Hide
        Ted Goddard added a comment -

        Restoring the following code is sufficient to fix the integration with Spring Web Flow 2 as tested by the swf-booking-icefaces example. The actual fix remains to be determined; for instance, why does the current state saving implementation not suffice for SWF and why does SWF require the "extra" BridgeExternalContext.release() call? (The "extra" release call is likely required because of the differences introduced by the SWF2 external lifecycle.)

        — src/com/icesoft/faces/application/D2DViewHandler.java (revision 17947)
        +++ src/com/icesoft/faces/application/D2DViewHandler.java (working copy)
        @@ -159,11 +159,11 @@
        }
        renderResponse(context);

        -// if ( CoreUtils.isJSFStateSaving() ) {
        -// StateManager stateMgr = context.getApplication().getStateManager();
        -// stateMgr.saveSerializedView(context);
        + if ( CoreUtils.isJSFStateSaving() )

        { + StateManager stateMgr = context.getApplication().getStateManager(); + stateMgr.saveSerializedView(context); // JSF 1.1 removes transient components here, but I don't think that 1.2 does -// }

        + }
        }

        Index: src/com/icesoft/faces/context/View.java
        ===================================================================
        — src/com/icesoft/faces/context/View.java (revision 17947)
        +++ src/com/icesoft/faces/context/View.java (working copy)
        @@ -153,6 +153,7 @@
        private void releaseAll()

        { facesContext.release(); persistentFacesState.release(); + ((com.icesoft.faces.context.BridgeExternalContext)facesContext.getExternalContext()).release(); }

        public BridgeFacesContext getFacesContext() {

        Show
        Ted Goddard added a comment - Restoring the following code is sufficient to fix the integration with Spring Web Flow 2 as tested by the swf-booking-icefaces example. The actual fix remains to be determined; for instance, why does the current state saving implementation not suffice for SWF and why does SWF require the "extra" BridgeExternalContext.release() call? (The "extra" release call is likely required because of the differences introduced by the SWF2 external lifecycle.) — src/com/icesoft/faces/application/D2DViewHandler.java (revision 17947) +++ src/com/icesoft/faces/application/D2DViewHandler.java (working copy) @@ -159,11 +159,11 @@ } renderResponse(context); -// if ( CoreUtils.isJSFStateSaving() ) { -// StateManager stateMgr = context.getApplication().getStateManager(); -// stateMgr.saveSerializedView(context); + if ( CoreUtils.isJSFStateSaving() ) { + StateManager stateMgr = context.getApplication().getStateManager(); + stateMgr.saveSerializedView(context); // JSF 1.1 removes transient components here, but I don't think that 1.2 does -// } + } } Index: src/com/icesoft/faces/context/View.java =================================================================== — src/com/icesoft/faces/context/View.java (revision 17947) +++ src/com/icesoft/faces/context/View.java (working copy) @@ -153,6 +153,7 @@ private void releaseAll() { facesContext.release(); persistentFacesState.release(); + ((com.icesoft.faces.context.BridgeExternalContext)facesContext.getExternalContext()).release(); } public BridgeFacesContext getFacesContext() {
        Hide
        Ted Goddard added a comment -

        See ICE-3827 for the change to D2DViewHandler.java and ICE-3566 for the change to View.java.

        Show
        Ted Goddard added a comment - See ICE-3827 for the change to D2DViewHandler.java and ICE-3566 for the change to View.java.
        Hide
        Ted Goddard added a comment -

        Another factor is that the following code is not present in restoreView:

        if (SeamUtilities.isSpringEnvironment()) {
        context = BridgeFacesContext.unwrap(context);
        if (context instanceof BridgeFacesContext)

        { ((BridgeFacesContext) context).setCurrentInstance(); }

        }

        This causes delegation to occur in restoreView because the FacesContext is wrapped, thereby interfering with the current state saving implementation.

        Show
        Ted Goddard added a comment - Another factor is that the following code is not present in restoreView: if (SeamUtilities.isSpringEnvironment()) { context = BridgeFacesContext.unwrap(context); if (context instanceof BridgeFacesContext) { ((BridgeFacesContext) context).setCurrentInstance(); } } This causes delegation to occur in restoreView because the FacesContext is wrapped, thereby interfering with the current state saving implementation.
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #17950 Mon Dec 01 15:08:23 MST 2008 ted.goddard unwrapped FacesContext and extra release for SWF2 (ICE-3799)
        Files Changed
        Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/application/D2DViewHandler.java
        Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/context/View.java
        Hide
        Ted Goddard added a comment -

        Changes have been checked in (using the unwrapping technique).

        Show
        Ted Goddard added a comment - Changes have been checked in (using the unwrapping technique).
        Ted Goddard made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Joanne Bai added a comment -

        successfully tested on ICEfaces trunk revision 17950

        Other revision info:
        spring-build - at revision: 495
        swf-booking-icefaces - at revision: 17947
        spring web flow - at revision: 14540

        Show
        Joanne Bai added a comment - successfully tested on ICEfaces trunk revision 17950 Other revision info: spring-build - at revision: 495 swf-booking-icefaces - at revision: 17947 spring web flow - at revision: 14540
        Ken Fyten made changes -
        Fix Version/s 1.8 [ 10161 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Assignee Ted Goddard [ ted.goddard ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Ted Goddard
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: