Firstly, the notion in the original JIRA that commenting out some lines in the BridgeFacesContext is a workaround no longer works in 1.8 RC1.
On observing the application in ICEFaces vs the original Spring+JSF application, it is obvious that the original application is an application in the POST-Process-Redirect model. Each page transition between webflow states is achieved via redirect, and as a result, the URL location bar always contains the latest webflow Flow ID, (like e2s3, e2s4, etc.) whereas in the ICEFaces example this is not true. The ICEfaces example is purely POST->UPDATE in style. The webflow ID is encapsulated in a hidden field in the forms by the FormRenderer, but this parameter is not included in any GET request of the page so the Webflow can never be resumed on any GET operation. As a result, the Webflow in this case is restarted, and the initial page of the flow is rendered.
Our documentation recommends having the "always-redirect-on-pause" parameter set to false for Ajax applications.
<!-- Executes flows: the central entry point into the Spring Web Flow system -->
<webflow:always-redirect-on-pause value="false" />
If this is false, reloads will never work. Period. Nor will any form of navigation using redirection. Note that you can have the default as false, but still have individual transitions defined to be using redirection, but not vice-versa.
So I enabled redirection for the application, but redirection wasn't happening. The flowId [executionId:snapshotId] showed up in the navigation bar once, but was never updated. That was because the common sendRedirect() method in SwfLifecycleExecutor is trying to set headers and use response codes, rather than calling the externalContext to do the redirection. So after navigating to the third page of the application, the location bar would still read e1s1 (for example) and hitting reload at this point threw an exception because that key is out of date. I changed this code to use the redirect method on the externalContext which helped.
Also, the flow Id argument when posted in the URL ("execution") is different from the name of the hidden field ("org.springframework.webflow.FlowExecutionKey"). I modified the apply() method to look for the "execution" parameter if the org......FlowExecutionKey" parameter is missing and this finds the proper flow id key for webflow resumption in all cases.
This method had problems too with the FacesContext no longer being bound to the ThreadLocal at the end of the apply() method. A FacesContext reference was passed to the original apply() method in SwfLifecycleExecutor, so I refactored the redirection methods to take the FacesContext as an argument and this now seems to work. I'm not sure why this was null. I'm also not sure about the reentrancy requirements of this method, so I'll leave the FacesContext as an argument to other internal methods.
I also can't find a compile time constant for the URL argument being generated by Spring: "execution". This is a likely a point of failure going forward as no one seems able to leave their argument names alone from one version to the next.
At this stage, the application seems to work fine if both redirecting and non-redirecting navigation is used. non-redirecting traffic resembles a normal AJAX application, is much faster feeling, but doesn't work in the case of reload. We could recommend this to clients who don't care about reload and/or for portions of the application where quick response is desired.
Redirecting navigation seems like an important aspect of some applications (banking, purchasing, etc.) where dual posting of page particulars would be a bad thing. See the description in the following page: http://www.ervacon.com/products/swf/tips/tip4.html