Same behavior is using Mojarra JSF.

Running HEAD of icefaces3-maintenance, with a full clean build, ran the showcase sample, and uploaded several small files, and could not reproduce the issue. I then re-built it without file size restrictions, and tested with several files that are a couple hundred MB, and could not reproduce the issue. Tested in Firefox and Chrome.

The only way that I could appear to reproduce it is if when I redeploy the showcase.war, if I forget to refresh my web browser, so that it is using all the view information from the last session, then it will upload and silently fail with nothing in the log and the page not changing. Using Firebug I can see that this is the response:

<h1>HTTP Status 500 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Exception report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>javax.servlet.ServletException: Session has expired
javax.faces.webapp.FacesServlet.service(FacesServlet.java:606)
</pre></p><p><b>root cause</b> <pre>org.icefaces.application.SessionExpiredException: Session has expired
org.icefaces.impl.application.ExtendedExceptionHandler.handle(ExtendedExceptionHandler.java:106)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
</pre></p><p><b>note</b> <u>The full stack trace of the root cause is available in the Apache Tomcat/7.0.23 logs.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/7.0.23</h3>

The fileEntry component uses a different AJAX method, and so when it gets these HTML error pages back, instead of changing the page from the JSF page to be the HTML error page, it silently eats it, since it's not an AJAX xml updates response. We could change fileEntry to actually show the error.

When running with showcase built with myfaces (ant -Dmyfaces="true"), it only uploads the first time for each demo. Subsequent uploads appear to work but the messages never change from the original upload. Refreshing the browser doesn't help either.

However, if you visit another fileEntry demo on the left menu and then return to the original demo, it will again for the next upload only.

Also, when this occurs there are no errors in either the tomcat log or the browser JS console.

Seeing the same issue with the ee composite component that wraps the ace:fileEntry. Does not appear related to serialization, as the same behaviour occurs with serialization on and off. Not seeing any session expired messages (client response or server side), but I am seeing a full page refresh on subsequent uploads. I'm also seeing a windows.disposed XHR call, which doesn't occur the first time the upload works, and this might be preventing the Multipart upload (as it's an XHR call).

Agree with Philip, a full page refresh is happening, as it is doing a full page post, and getting a full page response. The capture submit javascript is disappearing, so it's not doing the iframe ajax submit anymore. What is a little strange is that even with the full page updates, there are still giving the old message about the initial file and not the subsequent/current file.

And it only happens under MyFaces, not Mojarra.

The fileEntry capture submit code relied on a post add to view system event, that would inspect UIForm components to see if they had a fileEntry in them, and then would add components for rendering the capture javascript, and iframe, and disable the regular capture submit mechanism. With MyFaces, this system event was still happening, and the components were added to the UIForm, but those components were not being rendered. This change of form dom element children caused the whole form to be updated.

Likely the loss of the fileEntry capture submit meant that the FileEntryPhaseListener was not running properly, and so the uploads weren't being processed properly, so the old fileEntry results object was still in place, hence the unchanging messages.

Discussion with Deryk turned up ICE-7182, which was a MyFaces fix for the regular capture submit mechanism. Basically, the post add to view event was replaced with a pre render event. This was tried with the fileEntry capture submit, and it fixed uploading with MyFaces. Testing with Mojarra shows no problem with the new event.

icefaces-3.0.x-maintenance
Subversion 28428

icefaces3 trunk
Subversion 28429