Getting 'Cannot set header. Response already committed' with primefaces fileupload

Question

i am using jsf 2 (javax.faces-2.0.10.jar) and primefaces 3.5 on websphere 8.5.0.1 and i am also using the file upload jars:

• commons-fileupload-1.3.1.jar
• commons-io-2.4.jar

and i am trying to use primefaces fileupload component as follows:

<h:form  id="frm" enctype="multipart/form-data">
        <p:fileUpload id="fileUpload" value="#{uploadDocument.file}"
        fileUploadListener="#{uploadDocument.handleFileUpload}" mode="advanced" dragDropSupport="false"  
                   sizeLimit="10000000" fileLimit="3"  /> 
        </h:form>

web.xml config:

<filter>
       <filter-name>PrimeFaces FileUpload Filter</filter-name>
       <filter-class>org.primefaces.webapp.filter.FileUploadFilter</filter-class>
       <init-param>
            <param-name>uploadDirectory</param-name>
            <param-value>C:/uploadFolder</param-value>
       </init-param>
    </filter>

    <filter-mapping>
        <filter-name>PrimeFaces FileUpload Filter</filter-name>
        <servlet-name>Faces Servlet</servlet-name>
    </filter-mapping>

    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>/faces/*</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
      <servlet-name>Faces Servlet</servlet-name>
      <url-pattern>*.jsf</url-pattern>
    </servlet-mapping>

after choosing the file and clicking upload, the file is not uploaded and i am getting following warning in log file:

com.ibm.ws.webcontainer.srt.SRTServletResponse addHeader SRVE8094W: WARNING: Cannot set header. Response already committed.

please advise why the file upload is not working ?

Answer 1

The issue was because i had a jar called appbase.jar on my classpath when i removed it everything worked fine.

Answer 2

Obviously your response has been committed before the line throwing the exception. I've not seen the specific example you've got there, but the problem is quite common and there is a generic way to track these down. Something is being written to your response before you expected it to be, but the stacktrace you see is for a later event trying to add to that response. So, the solution is to record a stacktrace when the response is committed, and then at the later point when the exception is thrown, print this first stacktrace as well.

I don't have the code I used to use to do this to hand, as I wrote it for a previous company. I've put an outline solution below, that shows the gist of it-you need to wrap the response, and any servletoutputstream/printwriter objects it returns to detect the commit event. I've shown how this might be done by using introspection; but you can use ServletResponseWrapper and custom wrapper classes for the stream/writer if you prefer. In fact you don't need to wrap as many methods as I do here.

In our 'real' code, I recorded the stacktrace and printed it only when the problem occurred as described above, but the code below just logs when responses are committed, you can figure out which was which by looking at your logs.

public class BadCommitFilter implements Filter {
    public void doFilter(ServletRequest req, ServletResponse res,
        FilterChain chain) throws IOException, ServletException {

        HttpServletResponse response = (HttpServletRequest) res;
        response=Proxy.newProxyInstance(this.getClass().getClassLoader(),
                new Class[] { HttpServletResponse.class },
                new ResponseInvocationHandler(response, response));
        chain.doFilter(req, response);
    }
    private static class ResponseInvocationHandler<T> implements InvocationHandler {
      final T proxied;
      final HttpServletResponse response;

      public ResponseInvocationHandler(T proxied, HttpServletResponse response) {
        this.proxied = proxied;
        this.response = response;
      }

      public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        // in the 'real' code, I checked against a threadlocal
        // at the end only, so there was no possibility that I'd
        // miss out methods.
        boolean isCommitted = res.isCommitted();
        try {
          Object ret = method.invoke(proxied, args);
          if (ret instanceof PrintWriter) {
            Proxy.newProxyInstance(ret.getClass().getClassLoader(),
                new Class[] { PrintWriter.class },
                new ResponseInvocationHandler(ret, response));
          } else if (ret instanceof ServletOutputStream) {
            Proxy.newProxyInstance(ret.getClass().getClassLoader(),
                new Class[] { ServletOutputStream.class },
                new ResponseInvocationHandler(ret, response));
          }
        } finally {
          if(!isCommitted && res.isCommitted()) {
            try { throw Exception("First Committed:"); }
            // or however you want to log this
            catch(Exception e){e.printStackTrace();}              
          }
        }
        return ret;
      }
   }
}

If you have trouble with the code, there are some usual suspects to look for. Remember commitment can be triggered explicitly, but more often it is because you have written enough data to the buffer that it has to flush:

• using a jsp to dispatch to a servlet. Whitespace and content-type settings in jsps can push you over the buffer limit quite easily, you may not realise you'd written anything. Eg specifically jsps that do anything like <%@ page contentType="text/html; charset=UTF-8"%> but then forward to another servlet are wrong.
• setting large cookies. Cookies are headers, so count towards the buffer size
• servlet filters. Some apps have huge stacks of these, that can be over-eager to write headers.