If you write an ICEfaces application using Facelets, the context parameter delegateNonIface cannot be set to true of the application will fail. The problem was described in a separate case (ICE-2503) but I will copy and quote the relevant information here:

----
I did finally manage to replicate this issue. I tried the same test case with ICEfaces 1.6.0, 1.6.1, and 1.7 (from the current head of the repository). In addition to the standardRequestScope = true, I also had to have delegateNonIface = true. When these two context parameters are set as indicated, the problem occurs - even in a standard web application (i.e. it is not constrained to portlets).

In 1.6.0, the exception is as indicated in the original report:

java.lang.UnsupportedOperationException
        at javax.faces.context.ExternalContext.setResponse(ExternalContext.java:856)
        at com.sun.faces.application.ViewHandlerImpl.executePageToBuildView(ViewHandlerImpl.java:436)
        at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:114)
        at com.icesoft.faces.application.D2DViewHandler.renderView(D2DViewHandler.java:150)
        
In 1.6.1 and 1.7 from the head, the exception is slightly different:

java.lang.ClassCastException: com.icesoft.faces.env.PortletEnvironmentRenderRequest
        at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:110)
        at com.icesoft.faces.application.D2DViewHandler.renderView(D2DViewHandler.java:145)
        at com.icesoft.faces.application.D2DViewHandler.renderView(D2DViewHandler.java:145)

The main problem is basically the same, though, and stems from the ViewHandler delegation model. All registered ViewHandlers are put into a non-deterministic chain (a linked list of sorts with no specified order). To make this work, ViewHandlers need to be sure which views they should handle and which they should delegate. By setting delegateNonIface = true, the ICEfaces D2DViewHandler delegates responsibility to Sun's default ViewHandler implementation which, in this case, it shouldn't as we need to do the actual processing in the ICEfaces framework.

So the quick fix is to set delegateNonIface = false. This brings up a separate issue in that the use of delegateNonIface cannot be used with Facelets in ICEfaces. This should be captured in a separate JIRA. If the submitter can verify that the setting the delegateNonIface = false works for their application, the case can be resolved.
---