This could have side-effects for anything that uses action URLs, such as command
links and forms. From the documentation, of HttpServletResponse, it looks like
this code change should have no effect under most cases. However, the jsessionid
may be encoded into the URL, so that could affect applications where the
first page visited is an ICEfaces page prior to a session being established.

Although the correct url is now shown, when using push, the following exceptions occur:-
1)
11:51:01,253 ERROR [PersistentFacesState] Exception occured during execute push on Unknown View
javax.faces.FacesException: java.lang.NullPointerException
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:128)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:103)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.execute(PersistentFacesState.java:284)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.executeAndRender(PersistentFacesState.java:310)
at com.icesoft.faces.async.render.RunnableRender.run(RunnableRender.java:141)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.NullPointerException
at com.icesoft.faces.application.ViewRootStateManagerImpl.restoreView(ViewRootStateManagerImpl.java:105)
at org.jboss.seam.jsf.SeamStateManager.restoreView(SeamStateManager.java:76)
at com.icesoft.faces.application.D2DViewHandler.restoreView(D2DViewHandler.java:260)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:175)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
... 8 more

and the other one (both trace back to PersistentFacesState.execute (284):-
11:51:01,253 ERROR [PersistentFacesState] Exception occured during execute push on Unknown View
javax.faces.FacesException: java.lang.NullPointerException
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:128)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:103)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.execute(PersistentFacesState.java:284)
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.executeAndRender(PersistentFacesState.java:310)
at com.icesoft.faces.async.render.RunnableRender.run(RunnableRender.java:141)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.NullPointerException
at com.icesoft.faces.application.ViewRootStateManagerImpl.restoreView(ViewRootStateManagerImpl.java:105)
at org.jboss.seam.jsf.SeamStateManager.restoreView(SeamStateManager.java:76)
at com.icesoft.faces.application.D2DViewHandler.restoreView(D2DViewHandler.java:260)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:175)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
... 8 more

every once in a while, the conversationid comes out on the url as a page parameter. Looking at code in PersistentFacesState.execute...
Map requestParameterMap = facesContext.getExternalContext().getRequestParameterMap();
requestParameterMap.clear();
if (SeamUtilities.isSeamEnvironment())

then the following line is commented out:-

//Seam appears to need ViewState set during push
// see below
// requestParameterMap.put("javax.faces.ViewState", "ajaxpush");

not sure if this has anything to do with it as there is no comment on when this was commented out.
Anyhow, this exception is not consistent and can cause problems when it cannot find hibernate (no access to data). Still trying to figure out how to consistently get this exception thrown, but considering it has something to do with page parameters and conversationid occasionally getting parsed onto the url.

note that this example should be dropped into jboss-seam-2.2.0.GA/examples folder and that there is a readme file that also stipulates the "icefaces.home" property to be updated within build.xml of this application (ice-blog).

It was tested with latest from ICEfaces-1.8 trunk (p03 preview) on jboss-5.1.0.GA

add the following to index.xhtml within the data table to test this with <ice:outputLink>
<div id="linkexampleone" rendered="#

" >

<ice:outputLink id="icelink" value="/entry.xhtml" >
<f:param name="blogEntryId" value="#

"/>
<ice:outputText value="outputLink one"/>
</ice:outputLink>
</div>

this works just fine. The url that is encoded within the rendered markup stays the same throughout the entire time of testing. navigated away and back from the index page and did several pushes and it's all good. the uri that comes up when clicked and the one that is encoded all conform to seam-urlrewrite rules in pages.xml

encode method is now delegating to the underlying object, but further testing shows that the object is stale.

Change checked in for ICE-6791 should resolve response staleness.

Stale responses are no longer present during user interaction, but are present during Ajax Push. The proposed technique to resolve will be as follows:

Create a Servlet Filter to inject a FailSafeResponseWrapper. This must be in the Filter chain prior to the Seam Filters. The FailSafeResponseWrapper will allow encode*() to proceed using the Seam wrapper on the stale HttpServletResponse.

The attached FailSafeResponseFilter wraps the Response in a version that does not throw an Exception when it has gone out of request processing scope. It must be added to the web.xml prior to the Seam Filter:

<filter>
<filter-name>FailSafe</filter-name>
<filter-class>FailSafeResponseFilter</filter-class>
</filter>

<filter-mapping>
<filter-name>FailSafe</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

Since the specific failure seen by the customer has not been reproduced in the test application, the FailSafeResponseFilter contains substantial System.out output and is implemented in the default package so that it can be compiled directly within the "classes" directory or added to an existing project at the root level.

Updated to include FailSafeRequestWrapper.

Configured via:

<filter>
<filter-name>FailSafe</filter-name>
<filter-class>com.icesoft.faces.webapp.http.servlet.FailSafeResponseFilter</filter-class>
</filter>

<filter-mapping>
<filter-name>FailSafe</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>