ICEfaces
  1. ICEfaces
  2. ICE-5209

Glassfish 3 is logging warning when ICEfaces 2 is present

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-Alpha1, 2.0-Alpha2
    • Fix Version/s: 2.0-Alpha3, 2.0.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces 2 Glassfish 3

      Description

      This is being dumped out in the log everytime during each interaction with a simple application that uses ICEfaces 2

      WARNING: PWC4011: Unable to set request character encoding to UTF-8 from context /basic, because request parameters have already been read, or ServletRequest.getReader() has already been called

      It appears to be Glassfish specific and does not appear to have any functional impact.

        Activity

        Hide
        Deryk Sinotte added a comment -

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

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

        Show
        Deryk Sinotte added a comment - The Glassfish Wiki provides advice on how to turn this logging off: http://wiki.glassfish.java.net/Wiki.jsp?page=FaqWebAppUnableToSetRequestCharEncoding
        Hide
        Deryk Sinotte added a comment -

        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.

        Show
        Deryk Sinotte added a comment - 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.
        Hide
        Ted Goddard added a comment -

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

        Show
        Ted Goddard added a comment - this may be a bug in JSF 2.0: is it necessary for JSF 2.0 to use a particular request encoding?
        Hide
        Deryk Sinotte added a comment -

        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

        { context.getExternalContext().setRequestCharacterEncoding(encoding); }

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

        { log.fine(message); }

        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.

        Show
        Deryk Sinotte added a comment - 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 { context.getExternalContext().setRequestCharacterEncoding(encoding); } catch (UnsupportedEncodingException e) { // PENDING(edburns): I18N String message = "Can't set encoding to: " + encoding + " Exception:" + e.getMessage(); if (log.isLoggable(Level.WARNING)) { log.fine(message); } 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.
        Hide
        Ted Goddard added a comment -

        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.)

        Show
        Ted Goddard added a comment - 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.)
        Hide
        Mircea Toma added a comment - - edited

        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 .

        Show
        Mircea Toma added a comment - - edited 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 .
        Hide
        Ted Goddard added a comment -

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

        Show
        Ted Goddard added a comment - Please add details on the specific format of the new URI and what server-side pieces react to "donottouch".
        Hide
        Mircea Toma added a comment -

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

        Show
        Mircea Toma added a comment - 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".
        Hide
        Mike Geier added a comment -

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

        Show
        Mike Geier added a comment - This still occurs with IceFaces 3.0 RC1 and Glassfish 3.1 and 3.1.1. Has this been addressed?

          People

          • Assignee:
            Mircea Toma
            Reporter:
            Deryk Sinotte
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: