It looks like the progress code is trying to access the inputFile's progressListener bean, but it can't. I think it's because that bean is in request scope, and that other lifecycles, like WebMC chat server pushes, and the new inputFile form posts, may be deconstructing/constructing the request scoped bean Map, while the inputFile is trying to access it, effectively outside of a request. Actually, from how the OnDemandRenderer works, which is called from the progressListener itself, a previous invocation of the OnDemandRenderer might interfere with a subsequent progress update, without even needing the other types of lifecycles. It's just that the more we add, the more reproducible this may become.

The simplest work-around, which seems to have helped, was to not actually use the progressListener to call the OnDemandRenderer, but instead to just use the form post notifications, meant for synchronous mode, to update an indeterminate progress bar. Mandeep didn't seem to be able to reproduce it after that.

Another work-around may be to just use a session scoped bean.

To make this less likely to happen, and also for backwards compatibility, we should probably do:
ICE-3122 : iinputFile selectively post form
http://jira.icefaces.org/browse/ICE-3122

But, the real solution will involve investigating how we alter the request Map, and putting protection around that, which we'll use in the UploadServer, around when it tries to access the progressListener bean.

This affects the sample-jsf-icefaces-portlet for Liferay too.

Changing the bean to session scope only works for the first upload. Upon the second and third upload, it starts to fail again.

We've also been seeing this intermittently in 1.7.1, and with a session scoped bean (not a request scoped bean).

We've actually run into a similiar problem in our own code. We run some UI processes on separate threads, and those are given access to the same FacesContext as the request thread that spawned them. We occasionally ran into the same exception when those background threads tried to lookup managed beans. We've been able to avoid them for quite a while now by doing a simply retry: If we retry evaluating the EL expression to get the managed bean a couple times, we do eventually get it, but we haven't been able to track down the root cause of it.

I committed the fixes for ICE-3187 and ICE-3235 together.

The UploadServer now participates in locking that the PersistentFacesState uses to keep concurrent lifecycles from happening. The goal being that, when the lifecycle manages the request map, the InputFile's access of the progressListener bean will no longer coincide, so we shouldn't have the race condition of the progressListener sporadically being inaccessible.

TRUNK
Subversion 17608
ICEfaces 1.7 branch
Subversion 17609
icefaces\component\src\com\icesoft\faces\component\inputfile\InputFile.java
icefaces\core\src\com\icesoft\faces\component\FileUploadComponent.java
icefaces\core\src\com\icesoft\faces\webapp\http\core\UploadServer.java
icefaces\core\src\com\icesoft\faces\webapp\xmlhttp\PersistentFacesState.java

Added more of the locking protection, to wrap all accesses to the bean, via the file value binding, the progressListener method binding, and the action and actionListener method bindings.

TRUNK
Subversion 17658
ICEfaces 1.7 branch
Subversion 17657
icefaces\component\src\com\icesoft\faces\component\inputfile\InputFile.java
icefaces\core\src\com\icesoft\faces\component\FileUploadComponent.java
icefaces\core\src\com\icesoft\faces\webapp\http\core\UploadServer.java