This still occurs with IceFaces 3.0 RC1 and Glassfish 3.1 and 3.1.1. Has this been addressed?

Form submits triggered as follow up to push notifications have the request URI marked with "ice.session.donottouch" path parameter. On the server these marked requests will not update session's last access time. Only the requests triggered by direct user interaction should update session's last access time.
For example, if the form has the request path "auction.jsf" and web context is "auction" the marked request URI will look like "/auction/auction.jsf;ice.session.donottouch". The same form submit triggered by a button click or key press will look like "/auction/auction.jsf".

Please add details on the specific format of the new URI and what server-side pieces react to "donottouch".

Replacing the query parameter with a header is not possible because jsf.ajax.request does not allow adding custom headers to the request. Also changing the URL path to mark the request would change the viewId calculated by JSF.
So the solution chosen was to use a URI parameter to mark requests used to retrieve updates. This way the path parts are not affected. See an explanation of how path parameters can be used here: http://doriantaylor.com/policy/http-url-path-parameter-syntax .

Which requests have "ice.session.donottouch" set? Perhaps we can indicate this behavior in a different way (such as in the URL path).

(Just some notes in case we need to report this as a JSF bug: This does appear to be a problem in JSF or perhaps the Servlet API – it appears impossible to extract parameters from requests in ServletFilters while making use of specific encodings. It would seem useful to be able to change the encoding and have the data in the request parsed as it is requested, under the current encoding.)

The call to set the character encoding is called in javax.faces.application.ViewHandler.initView() method:

public void initView(FacesContext context) throws FacesException {
String encoding = calculateCharacterEncoding(context);
if (null != encoding) {
try

catch (UnsupportedEncodingException e) {
// PENDING(edburns): I18N
String message = "Can't set encoding to: " + encoding +
" Exception:" + e.getMessage();
if (log.isLoggable(Level.WARNING))

throw new FacesException(message, e);

}
}
}

This method is called from the RestoreViewPhase class. The actual warning is from the container (Glassfish in this case), not JSF.

The container is correct to not allow this (and presumably warn about it), but Tomcat does not complain. Not sure if the encoding not being set could lead to other issues or not.

this may be a bug in JSF 2.0: is it necessary for JSF 2.0 to use a particular request encoding?

Looks like the culprit is in our ICEfacesResourceHandler.isResourceRequest method. There is a conditional check where we read a request parameter:

if (!resourceRequest && servletRequest.getParameter("ice.session.donottouch") == null) {...

This request parameter is read before the lifecycle is executed. The RestoreViewPhase is where the encoding is set but it occurs after our ResourceHandler has attempted to read the parameter. To get rid of the warning, we'd need to find a different way of getting the information instead of reading the parameter. For an experiment, I simply commented out the call to getParameter and the warnings went away.

The Glassfish Wiki provides advice on how to turn this logging off:

http://wiki.glassfish.java.net/Wiki.jsp?page=FaqWebAppUnableToSetRequestCharEncoding