Details
Bug
Major
Description
When standardRequestScope is enabled, some values appear to be retained from previous requests.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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() )
+ }
}
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()
public BridgeFacesContext getFacesContext() {
See ICE-3827 for the change to D2DViewHandler.java and ICE-3566 for the change to View.java.
Another factor is that the following code is not present in restoreView:
if (SeamUtilities.isSpringEnvironment()) {
context = BridgeFacesContext.unwrap(context);
if (context instanceof BridgeFacesContext)
}
This causes delegation to occur in restoreView because the FacesContext is wrapped, thereby interfering with the current state saving implementation.
Changes have been checked in (using the unwrapping technique).
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
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.