• Added method to FileInfo to update it's status, fail the lifecycle and delete the uploaded file. Documented that if immediate=false, then it's too late to fail the lifecycle.

• Noted that FacesMessages are generated before the fileEntryListener, so for the update method to have visual effect, needed to redesign when FacesMessages are added. It used to happen on decode, whether new results or not, so the FacesMessages would continue to display until the next upload operation. Now, we need to add the FacesMessages some time after the fileEntryListener is invoked, which if it's done right after event broadcasting would tie the adding to only the upload lifecycle, so they would not display as long. An alternative, for greater backwards compatibility, would be to always add them PreRender, after any fileEntryListener may be invoked. Or to always add file events, which will always add FacesMessages, but which have a flag for optionally invoking the listener first, only if an upload happened this lifecycle. Temporarily sided with only adding FacesMessages on upload lifecycle, since limited feedback was that anything else would be unnecessary and redundant. In comp team meeting agreed that for better compatibility with compat components, which do partial submits, would retain older behaviour of always re-adding FacesMessages, on every execute, using the technique of always queuing events, which are flagged to conditionally invoke the listener.

• Added default validation, which happens in decode, before any possible custom validation, where if any files failed, then fail the lifecycle. This makes it impossible to unfail a file, which makes sense, since the file would have already been deleted anyway. This stops UpdateModel phase from happening, but still invokes the fileEntryListener.

• Custom validation was not reflecting in results, investigation showed it was because apps are getting cloned results. Decided to not clone, since results can be ValueExpression, and in bean anyway. Documented that applications should save clones of FileEntryResults or FileInfo objects.

• Fixed issue with ace-test where old icepush configuration in web.xml was keeping fileEntry progress from working. Really confused things, when ace-showcase was working, but ace-test was not.

• Regression of sorts, where when file has completed uploading, fileEntry CSS state remains uploading, not complete. Possibly try unregistering push notifications in 100% progress one. No, that's before the JSF lifecycle has really ran, the difference between 100% progress and complete is quite useful. Just remembered that icepush.jar was updated, that might be it. Reverted to the Beta1 version of icepush.jar, but that didn't change anything. Added code to progress handler to not apply progress after switched to complete state. That fixed it.

• Testing procedures described, and test ui provided, in form16 of: icefaces2/ace/test/web/fileEntry.xhtml

Component changes
Subversion 23595

Test and example app changes
Subversion 23596

I suppose it doesn't working now with icefaces 3.3 from trunk.

Custom FileEntryStatus added to fileEntryListener are not displayed. Only generic FileEntryStatuses are visible.

Sample code
if (!allowEmptyFile)

if (useFileChecker)

Sorry. My mistake. Above scenario works.