JSF 2.2 - fileupload does not work with Ajax. Form appears to have incorrect enctype (only via AJAX)

Trying to implement the JSF 2.2 example I have the following code:

<h:form prependId="false" enctype="multipart/form-data">

    <!-- Now it's the AJAX file upload component -->
    <h:inputFile id="fileUpload" value="#{someBean.file}" >
        <f:ajax />

    <h:commandButton value="Upload" />

According to some JSF 2.2 this should work but in my case it is giving me the following error:

the request doesn't contain a multipart/form-data or multipart/mixed stream, content type header is application/x-www-form-urlencoded;charset=UTF-8

Looking into the request although I have set my form enctype correctly, the partial request submits:

Content-type:application/x-www-form-urlencoded;charset=UTF-8 Faces-Request:partial/ajax

Note that web.xml also was modified to:

    <servlet-name>Faces Servlet</servlet-name>

I am using Mojarra 2.2.0-m15 but tried this with earlier versions as well. Does anyone know any useful info about this issue, which I assume is a bug?


I'm not sure what's going on as I haven't seen this before. The following construct works for me when using the today's Mojarra 2.2.1 snapshot which you can download from the "implementation jar" link mentioned in What's new in JSF 2.2?

<h:form enctype="multipart/form-data">
    <h:inputFile value="#{bean.file}" required="true">
        <f:ajax listener="#{bean.handleFileUpload}" render="@form" />
    <h:messages />


private Part file;

public void handleFileUpload(AjaxBehaviorEvent event) {
    System.out.println("file size: " + file.getSize());
    System.out.println("file type: " + file.getContentType());
    System.out.println("file info: " + file.getHeader("Content-Disposition"));

// ...

I recommend to give the newer Mojarra version a try. Apparently there was a bug in an older Mojarra version which failed to create a proper multipart/form-data request using the <iframe> hack which ultimately caused this error. The mXX versions are beta versions anyway and should not be relied upon for production. This error could theoretically also have been browser-specific, but it works currently fine for me in Chrome 26, Firefox 20 and IE 10.

The only issue which I'm seeing is that the hidden <iframe> is still visible in Chrome and Firefox as below:

It appears that they're forgotten to set frameborder attribute to 0 in the generated <iframe>. I've reported issue 2861 about that.

Need Your Help

SOAP Web Service: do you need the WSDL publication page?

web-services api soap asmx

SOAP Web Service: do you need the WSDL publication page?

Java container managed transactions

java hibernate jpa transactions ejb

I have encountered a problem and I can't figure out the cause. For the rest of the post, we shall assume that every transaction is container managed and that we use jboss AS 7.X. We have three stat...

About UNIX Resources Network

Original, collect and organize Developers related documents, information and materials, contains jQuery, Html, CSS, MySQL, .NET, ASP.NET, SQL, objective-c, iPhone, Ruby on Rails, C, SQL Server, Ruby, Arrays, Regex, ASP.NET MVC, WPF, XML, Ajax, DataBase, and so on.