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 ?"
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.