I have been using RF since 3.3.x, and one of the components I use fairly prominently is rich:fileUpload. My web application is running on Tomcat behind an Apache httpd server (using mod_jk). After a lot of hard work, I managed to upgrade from RF3.3.3 and JSF 1.2 (RI) to RF4.2.1 and JSF 2.1 (RI).
The goal for the page with fileUpload is to limit the maximum total size of all fileUploads, not necessarily the number of attachments or the size of an individual attachment. For example, I want to limit users to 20mb of file uploads. In 3.3.3, I accomplished this by tracking the total size in the bean with the file upload listener and throwing an exception if the total size limit was exceeded. In the XHTML, I used the onerror and onsizerejected attributes of the rich:fileUpload element to display the error message. This worked well, since if the back-end threw an Exception, the onerror handler would fire.
In RF4.2, the file upload element no longer has the onerror attribute. I was able to work around this, actually, because I can still track the total size in the bean and flip a boolean value if there is a size error. I set a a4j:ajax element to re-render a script block that reads the boolean flag to display the error. So what happens is that the upload completes, the file upload listener records the total size and if there is a violation of the maximum total size, it flips the error condition flag and calls the error display function, and then the ajax event fires, causing the error message function to be switched on and it is displayed.
This is all very nice until I deploy into my httpd/Tomcat environment. My httpd conf specifies a maximum request size (say 50mb). If the upload is larger than that, httpd just aborts the connection. In RF3.3, this was actually OK, because the error event still fired (and for the right reason, for my purposes at least). In RF4.2, fileUpload no longer has the error event and in fact seems to behave worse than the RF3.3 implementation. What happened in RF3.3 is that after the aborted POST, the status calls would detect that the file upload failed and trigger the error event. In 4.2, the aborted POST still happens, but the status polling never stops (and the RF servlet continuously returns 0). The user is left with a file upload component in a sort of "in-between" state.
I would think that this is a common enough thing that there has to be a way to handle it. If the initial POST aborts like that and the status calls always return 0, then it should be possible to detect that the upload was dropped completely. I would think that the back-end servlet should be able to respond with "I've never heard of this upload, so there must be some kind of error." I also see a NPE come up. Any ideas?