Tested with the showcase app using Mojarra 2.2, for both regular uploads and callback uploads, and they both worked fine. So this is specific to the tutorial app, and not the ace:fileEntry component itself.

I had to fix the tutorial build process so that it wouldn't use the hard-coded jar name of "javax.faces.jar", and instead just use whatever jars are in the lib/mojarra folder, since it nows adds the version to the jar file name, like maven would. After that I was able to reproduce the problem with Mojarra 2.2.0.

Possibly the earlier test with javax.faces-2.2.0-m15.jar and showcase was in error, or there were changes between javax.faces-2.2.0-m15.jar and javax.faces-2.2.1.jar, but from testing of showcase.war and file-callback-tutorial.war using javax.faces-2.2.1.jar, they both fail with ace:fileEntry uploads.

The cause seems to be the @MultipartConfig annotation on the FacesServlet, that was not there for Mojarra 2.1.x, which is causing there to be nothing for the commons-upload FileItemIterator. Will investigate using the Servlet 3.0 Parts API directly, although this will affect percent progress pushing, which was initiated by the commons-upload ProgressListener.

Had to reconcile code that handles \ escaping of ; ' " in the file names with IE full path handling that removes file path info and uses the file-system separator which is \ on Windows.

The file-callback-tutorial progress issue was due to old app CSS that predated the change to using themeroller for the fileEntry styling. Removed it.

Re-wrote the upload handling to more separate the Parts and Apache Commons code paths, to accommodate the Parts write and delete methods. There is essentially no server initiated progress though, and so will require investigation of client-side progress, or some kind of server interception of request bytes before they become parsed and cached Part objects.

Mojarra 2.2.1 seems to be part-way through developing the necessary support for file uploading via XHR[2]. Not enough hooks are in place for us to use them and add the file sending, without patching jsf.js itself. But possibly we can use the "begin" event to add progress event listening.

1856:    sendEvent(req.xmlReq, req.context, "begin");
1857:    req.xmlReq.send(content);

They're using the XHR1 send(String) call instead of the XHR2 send(FormData) call that would encapsulate form fields and file fields.

var formData = new FormData(form);             // Existing form fields including input type=file
formData.append('secret_token', '1234567890'); // Additional params as encoded in lines 1826-1833

Committed everything, which allows for proper uploading in all the scenarios. The only issue being that there is no progress in Servlet 3 + Mojarra 2.2.x, but that has been spun off into ICE-9516.

icefaces3 trunk
Subversion 37399

Fixed minor regression where the size for failed file upload should be zero.

icefaces3 trunk
Subversion 37714

Reopening issue.

After investigating ICE-9589, it was found that code committed for solving this issue (ICE-9273) contains a call to HttpServletRequest.getParts() and use of javax.servlet.http.Part objects, which are only available in the Servlet 3.0 API, and not in previous Servlet versions. Thus, ace:fileEntry is not working on Tomcat 6, for example, and any other server that uses a Servlet API earlier than 3.0. Refactoring this code will be necessary to make ace:fileEntry work with earlier Servler API's.

Committed fix at revision 38314. Replaced use of javax.servlet.http.Part with use of Apache Commons FileUpload classes in order to restore compatibility with Servlet 2.5 API.

The test case in this JIRA is confirmed fixed Tomcat 6, 7, IE 7, 8, 9, 10, FF 3.6, 21, Chrome 29. Revision # 38328.
Regression tests for fileEntry were run in Tomcat 6 and 7 with FF 21, IE 9 and Chrome 29. All passed manually.