Right now, if you want to use an ice:inputFile with an ice:outputProgress component, you have to use a lot of glue code in the bean, to hold the percent progress, and more importantly, to kickoff a render to show that progress.

Particularly the challenge is that, with Seam, while the pre-upload render in the main servlet has access to the PersistentFacesState for its rendering, the during-upload render in the UploadServer does not have access to it, which means that when the UploadServer calls the InputFile component, which calls the bean's progressListener, there's non-trivial code in the bean's progressListener that has to hold the PersistentFacesState from the pre-upload render, to use for the during-upload render.

We can remove all of that glue logic, if the InputFile does two things:

1. Grab the PersistentFacesState when it renders itself. Technically the InputFileRenderer handles this, but it actually delegates back to InputFile for rendering the IFRAME. Then, when setProgress(int) is called on the InputFile, is can invoke the progressListener, and simply initiate the render itself.

2. Add an attribute to the InputFile (called outputProgress?) that would have the outputProgress' id, so it can look it up, and simply call something like OutputProgress.setValue(this.getProgress()).

Now, the usage of #2 would be what sets off #1, since we don't want both the InputFile and any legacy bean progressListener code firing off a render. The contract of the outputProgress attribute would be that the application is asynchronous, and that the ice:outputProgress component is not trying to use a ValueBinding for its value attribute, and that any progressListener is not going to be using the renderManager.

One difference is that renderManager.requestRender seems to be doing a bit more than just PersistentFacesState.execute() then render(). So that should be looked into.