ICEpush just needs to better handle the concept of pushes being done for a while, and then stopping. It seems to assume that it's an error if pushes are finished.

Using diagnostic header added in PUSH-124, it is evident that listen.icepush.jsf is being requested twice from the same page.

On the server side, all fileEntry calls to icepush are through: org.icefaces.component.fileentry.PushUtils. Note that removePushGroupMember is not being used.

On the client side, the code is in: icefaces2/ace/component/resources/org.icefaces.component.fileentry/fileEntry.js
In formOnsubmit we call: window.ice.push.register(regPushIds, function(pushedIds);
In iframeOnloadHandler there's commented out code to call: window.ice.push.deregister(unregPushIds);

The client-side push id is actually rendered from the server-side, from code that calls the PushUtils call to get a push id.

Since only window.ice.push.register is being called from the client, if that means that multiple requests to the server are happening, then that points to a flaw in window.ice.push.register possibly not properly handling being used by multiple push ids in a page.

Pushing this out for consideration in a future release due to the fact that is has no functional impacts. The following entry has been added to the ICEfaces 2.0.0 Release Notes for it:

• ace:fileEntry - occasionally the JavaScript error "Failed to load resource: javax.faces.resource/listen.icepush.jsf" will appear in the JavaScript console after a successful file upload. This error can be ignored as it has no functional impact.

We should re-verify this and discuss. We've changed the way the resource calls are handled and how they respond. If the error message is still occurring we need to determine how to deal with it.

Assigning to Mark to verify failure in current build.

I am unable to reproduce this JS error using the ace:fileEntry demo in the showcase application. This was tested on ICEfaces3 Trunk Revision# 27336 using IE7/9, Firefox3.6, Chrome16. Marking as resolved.