After doing the analysis of how resources are served and some debugging for confirmation I can definitely affirm that flash, view and window scoped resources cannot be properly looked up when requested.
The reason is that the request for resource is processed outside the JSF lifecycle. For example the view scoped beans cannot be looked up because the view map does not exist since a view root object is not created. Same goes for window and flash scoped resources. The application and session scoped bean do work because the application and session can be identified from the resource request.

The obvious solution to this is to append a new parameter to the resource's URL which will identify the scope instance on the server. In the case of window scoped resources the window ID is the obvious candidate. For view scoped resources the ViewState string can be used, but restoring the state of the view root (and consequently its view map) can cause performance issues when lots of resources are looked up.

Implemented resource lookup for window and view scopes. Previously the resources could not be located since the previous implementation was relying on the continuous existence of the view map or the window scope. To solve the issue URL parameters where added to the resource request URL to help with the finding of the correct scope map, even after the JSF lifecycle that rendered the page (referencing the resources) has ended.

Removed the ability to register resources in flash scope because flash is not setup the same way the other scopes are working. There cannot be beans that are flash scoped, there is only a "flash" EL variable provided by JSF which has the properties of a Map.

Modified icefaces/samples/core/test/dynamicResource application to include tests for all the scopes the dynamic resources can be in.

rev. 45969