Looks like 1.8.0dr1 behavior is related to following report
http://www.icefaces.org/JForum/posts/list/9548.page

BridgeFacesContext versions as per issue description above.

I'm unable to run the provided .war file on JDK 1.5 with tomcat 6.0.18. I'll see if similar behavior can be reproduced with the SWF booking sample.

Nov 11, 2008 1:56:27 PM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'authenticationProcessingFilterTemplate' defined in class path resource [com/wire/common/resources/spring/client/ctx/securityCtx.xml]: Could not resolve placeholder 'application:application'
at org.springframework.beans.factory.config.PropertyPlaceholderConfigurer.processProperties(PropertyPlaceholderConfigurer.java:268)
at org.springframework.beans.factory.config.PropertyResourceConfigurer.postProcessBeanFactory(PropertyResourceConfigurer.java:75)
at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:554)
at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:528)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:363)
at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3843)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4342)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:830)
at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:719)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

The following parameter is needed to run the test:

-Dconfig.filename=dev

However, I will need to contact the reporter for additional information on the expected behavior of the test.

Instructions from bug reporter:

In the working situation, enter a value and click submit button to go to second page of webflow. Hit refresh on browser and you will stay on that second page
In non-working situation you will go back to page one.. i.e: the flow restarts where the flow state should have persistent through the refresh and you should have stayed on page 2.

Any progress on this?

Tyler, do you still have the test case somewhere? I cannot find it on the FTP server. Without it I can just guess what could go wrong...

After debugging and analyzing the provided source code I am convinced that ICEfaces behaves as expected. On a page reload only the fragment included with webflow:include tag is reset. The fragment is rendered by org.springframework.faces.ui.IncludeViewHandler and the decision of what page needs to be included belongs to org.springframework.webflow.engine.ViewState.
This stack trace shows how Spring Webflow and ICEfaces interact:
at org.springframework.faces.ui.IncludeViewHandler.renderView(IncludeViewHandler.java:57)
at org.springframework.faces.webflow.JsfView.render(JsfView.java:97)
at org.springframework.webflow.engine.ViewState.render(ViewState.java:245)
at org.springframework.webflow.engine.ViewState.resume(ViewState.java:204)
at org.springframework.webflow.engine.Flow.resume(Flow.java:545)
at org.springframework.webflow.engine.impl.FlowExecutionImpl.resume(FlowExecutionImpl.java:262)
at org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:163)
at org.springframework.faces.ui.WebFlowBoundaryComponent$1.doInComponentContext(WebFlowBoundaryComponent.java:66)
at org.springframework.faces.ui.WebflowTemplate.doExecute(WebflowTemplate.java:104)
at org.springframework.faces.ui.WebflowTemplate.execute(WebflowTemplate.java:51)
at org.springframework.faces.ui.WebFlowBoundaryComponent.encodeChildren(WebFlowBoundaryComponent.java:58)
at com.icesoft.faces.renderkit.dom_html_basic.DomBasicRenderer.encodeParentAndChildren(DomBasicRenderer.java:354)
at com.icesoft.faces.renderkit.dom_html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:96)

The test case does work with 1.7.2 release because ICEfaces used to execute only the render phase on a page reload. Since ICE-3944 was fixed the full lifecycle is executed, including "Restore View" phase.
In conclusion I believe it is org.springframework.webflow.engine.ViewState's responsibility to remember the page it needs to render and not ICEface's/JSF.

Perhaps you can explain the following then:
I upgraded to 1.8.0DR2 and I got another completely separate issue with stack trace shown below.

I was able to circumvent this error by setting following attribute to false instead of true as in test case
<context-param>
<param-name>com.icesoft.faces.doJSFStateManagement</param-name>
<!-- when following is true: java.lang.IllegalStateException: Duplicate component ID '_id1' found in view. -->
<param-value>false</param-value>
</context-param>

When doing so then everything works again. i.e: going to page 2 and refreshing the state is not lost and it is in fact correctly maintained.

1) Please explain then your above assertion. 2) determine what can be done to have test case work with this parameter set to true
-------------------------------------------------------....

java.lang.IllegalStateException: Duplicate component ID '_id1' found in view.
at com.sun.faces.application.StateManagerImpl.checkIdUniqueness(StateManagerImpl.java:201)
at com.sun.faces.application.StateManagerImpl.checkIdUniqueness(StateManagerImpl.java:204)
at com.sun.faces.application.StateManagerImpl.checkIdUniqueness(StateManagerImpl.java:204)
at com.sun.faces.application.StateManagerImpl.checkIdUniqueness(StateManagerImpl.java:204)
at com.sun.faces.application.StateManagerImpl.saveSerializedView(StateManagerImpl.java:97)
at org.springframework.faces.webflow.FlowViewStateManager.saveSerializedView(FlowViewStateManager.java:129)
at com.icesoft.faces.application.D2DViewHandler.invokeStateSaving(D2DViewHandler.java:731)
at com.icesoft.faces.facelets.D2DFaceletViewHandler.renderResponse(D2DFaceletViewHandler.java:284)
at com.icesoft.faces.application.D2DViewHandler.renderView(D2DViewHandler.java:156)
at org.springframework.faces.ui.IncludeViewHandler.delegateViewHandler(IncludeViewHandler.java:268)
at org.springframework.faces.ui.IncludeViewHandler.renderView(IncludeViewHandler.java:258)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:107)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:245)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:137)

The codebase appears to have migrated quite a bit since this original patch was tried. Commenting out those lines of code no longer works, however the issue is still valid and has been fixed in http://jira.icefaces.org/browse/ICE-4186.

The upshot of the fix is to enable the redirect-on-pause setting in the src/main/webapp/WEB-INF/config/webflow-config.xml file as follows:

<webflow:flow-executor id="flowExecutor">
<webflow:flow-execution-attributes>
<!-- #4186 comment out for reload support, include for POST-UPDATE type behaviour -->
<!-<webflow:always-redirect-on-pause value="false" />->
</webflow:flow-execution-attributes>
<webflow:flow-execution-listeners>
<webflow:listener ref="jpaFlowExecutionListener" />
<webflow:listener ref="securityFlowExecutionListener" />
</webflow:flow-execution-listeners>
</webflow:flow-executor>

You can comment it out, since the default is "true". Note that this enables the POST->process->REDIRECT pattern as outlined in the 4186 case and disables the faster and more streamlined POST->process-> send updates model in ICEFaces AJAX processing but the two modes are not compatible.

This particular issue is now resolved. If there are further issues related to reload, please refer to 4186 above.