I built the applications included in the 1.7 beta1 release using the default build command and then replacing jsf-api.jar and jsf-impl.jar for the ones in the Sun JSF 1.2_07 RI release. I tested these applications with and without the 'com.sun.faces.enableRestoreView11Compatibility' context parameter. All the applications were deployed on Tomcat 6.

These are the results:
All the applications show exactly the same behaviour with or without the above mentioned context parameter set to 'true'. Both versions of Component Showcase (facelets and non-facelets) display the main page, but one is unable to do anything. Auction Monitor is not displayed at all. Instead, an error page is shown giving the details of the exception. Address demo is the only application that works normally to some extent.

Here are the details:

Component Showcase (non-facelets)
Clicking on any item of the menu tree doesn't load anything. Changing the theme doesn't do anything as well. The connection status icon always shows no connection. After clicking the reload button on the browser, the page was completely blank. After removing cookies and reloading, the page was displayed again, but still it wasn't possible to interact with it. When clicking anything in the menu tree, something like this appeared in the
console:
SEVERE: JSF1054: <Phase ID: RENDER_RESPONSE 6, View ID: /showcase.iface> Exception thrown during phase execution: javax.faces.event.PhaseEvent[source-com.sun.faces.lifecycle.LifecycleImpl@c749e4]

Component Showcase (facelets)
It shows pretty much the same behaviour as the non-facelets version. First, I want to note that I had to delete el-api.jar and el-ri.jar from the WEB-INF/lib folder, otherwise, I got a java.lang.LinkageError exception. The only difference is that when clicking on anything on the page, one can see the full stack trace of the exception:
SEVERE: Problem in renderResponse: null
java.lang.UnsupportedOperationException

Auction Monitor
The page wasn't displayed at all. Instead, an exception page appeared reporting a java.lang.UnsupportedOperationException. This message appeared in the console:
SEVERE: JSF1054: <Phase ID: RENDER_RESPONSE 6, View ID: /auctionMonitor.iface> Exception thrown during phase execution: javax.faces.event.PhaseEvent[source-com.sun.faces.lifecycle.LifecycleImpl@cb2185]

Address Demo
This was the only application that worked normally to some extent. When the application displayed error messages after entering incorrect values in the form, a message like this appeared in the console:
INFO: WARNING: FacesMessage(s) have been enqueued, but may not have been displayed. sourceId=iceForm:state[severity=(INFO 0), summary=(State not found with Zip 75001. Our best guess is TX), detail=(State not found with Zip 75001. Our best guess is TX)]

When I closed the tab and then navigated again to http://localhost:8080/address/ the page was completely blank, but if I went to http://localhost:8080/address/address.iface (or response.iface) the page was displayed normally.

I downloaded version 1.2_08, for some reason all the versions of 1.2_06 that I could find had jsf 1.2_05.xxxx show up on startup. I see the issues described above. On compilation, the first thing I see trying to run the application in Tomcat 6 is:

28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent
WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public char[] getChars()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.

28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent
WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public void flushContentToWrappedResponse()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.

28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent
WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public boolean isBytes()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.

28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent
WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public boolean isChars()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.

28-Feb-2008 2:32:57 PM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent
WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public void resetBuffers'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.

The object returned by the ServletExternalContext is just a HttpServletContext, and I don't think Tomcat 6 has the right servlet-api runtime jars. I tried the applications with JBoss 4.2.2, and they work fine.

Second, the BridgeFacesContext was throwing an UnsupportedOperationException when the getMaximumSeverity method was called. See http://jira.icefaces.org/browse/ICE-1127 This is the cause of the Exception that Arturo was seeing. I've fixed this, and now the applications come up.

Third, in Tomcat 6.0 the component-showcase comes up, and all pages work except for the RichText one. This appears to be doing some redirection of some kind, and the whole page shows up utterly blank. However, this page works in JBoss 4.2.2. Is this what they mean by: "Because of this, content will not be displayed correctly ?"

Please verify that 1.2-08 is working correctly with latest trunk.

Revision: 15897
Server: Tomcat6.0.14
JSF: 1.2_08

Same behaviour seen as described by Art on the commet above
1) warning messages displayed on compilation
Mar 3, 2008 10:26:56 AM com.sun.faces.taglib.jsf_core.ViewTag doStartTag
WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public void flushContentToWrappedResponse()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.
Mar 3, 2008 10:26:56 AM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent
WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public boolean isBytes()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.
Mar 3, 2008 10:26:56 AM com.sun.faces.taglib.jsf_core.SubviewTag createVerbatimComponentFromBodyContent

2)Clicking on any item of the menu tree doesn't load anything. The connection status icon always shows no connection. After clicking the reload button on the browser, the page was completely blank.

3) Mar 3, 2008 10:29:34 AM com.sun.faces.lifecycle.Phase doPhase
SEVERE: JSF1054: (Phase ID: RENDER_RESPONSE 6, View ID: /showcase.iface) Exception thrown during phase execution: javax.faces.event.PhaseEvent[source=com.sun.faces.lifecycle.LifecycleImpl@1d688e2]

Greg Disk wrote
"Second, the BridgeFacesContext was throwing an UnsupportedOperationException when the getMaximumSeverity method was called. See http://jira.icefaces.org/browse/ICE-1127 This is the cause of the Exception that Arturo was seeing. I've fixed this, and now the applications come up. "

What was fixed?
On Icefaces Rev 16026 at 14.03.2008 with jsf 1.2_08 I still see this error on start of my application
(no edit operations and validation errors)

java.lang.UnsupportedOperationException
at com.icesoft.faces.context.BridgeFacesContext.getMaximumSeverity(BridgeFacesContext.java:143)
at javax.faces.component.UIData.contextHasErrorMessages(UIData.java:1313)
at javax.faces.component.UIData.keepSaved(UIData.java:1287)
at javax.faces.component.UIData.encodeBegin(UIData.java:946)
at com.icesoft.faces.component.panelseries.UISeries.encodeBegin(UISeries.java:251)

Ok, I added the maxSeverity stuff and checked it in. I am checking the ServletSpec for 2.5 because, again,

WARNING: "JSF1062: WARNING! The response object returned by ExternalContext.getResponse() doesn't provide a method with signature 'public boolean isBytes()'. This method is necessary in order to provide content interweaving in a JSP environment. Because of this, content will not be displayed correctly.

is not a problem in our implementation. I'm certain jsf1.2_08 is using servlet 2.5, or some such thing with a newer API. But I will make sure.

The warnings turned out to be a JSF subclassing of the HttpServletResponseWrapper that appears to provide buffering between an instance of Servlet and Portlet Response classes. It looks as if they got rid of implementing the InterweavingResponse interface which has been deprecated, and instead, probe the Response object returned by the ExternalContext to see if they have the methods. I don't think it changes anything, but now the nasty warning message is printed.

I checked in a change to the PersistentFacesState class to get it to actually execute the renderResponse phase from a server push operation. The renderResponse method is called from within the LifecycleImpl class in our existing jsf-ri.jar file, but that no longer appears to be the case.

Scratch the change to PersistentFacesState. We need to know more about the lifecycle stuff.

There was code in the JSF restoreViewPhase that checks to see if the requestMap is devoid of this key:
ResponseStateManager.VIEW_STATE_PARAM

if so, it sets the responseComplete flag on the FacesContext and returns.

Our server push operations are in a bit of a grey zone. We don't really want to execute the JSF lifecycle from a server push operation because there's no point. There are no user parameters in a request map, so there's nothing to validate, no actionHandlers to call, etc. Plus it's bound to be expensive, time wise. The only reason we need to execute the JSF lifecycle at all is so that the Seam phase listeners can initialize Seam if we're in a Seam application.

What we really need to do is render the response. The last change I needed to make is to allow code in a server push environment to reset the responseComplete flag. This isn't to be done normally, because in the case of a normal postback from the user if the responseComplete flag is set (say navigation rule redirection) it should remain set. But it needs to be done here if we want our rendering code to be called at all.