There are two other sub-issues left to be solved before window lazy scope is fully functional:

a) When view scope beans are present in the page the lazy window scope should be automatically turned off because the disposal of the view scope beans rely on the 'dispose-window' request as well.

b) The pushIds used to identify views and managed by SessionViewManager have to be clean-up to avoid their accumulation.

Detect now if view scope map contains any beans. When beans are present the window lazy scope feature is disabled to make sure the 'dispose-window' request is sent.

It should be possible to rely on the automatic cleanup in ICEpush for session-based notification:

PushRenderer.addCurrentSession(groupName) records groupName in the session. (addCurrentViewsToGroup() would not be called as it is currently.)

For each JSF view created, PushContext.addGroupMember(groupName, viewPushId) is called for each groupName recorded in the session.

A list of views is not recorded by ICEfaces, and the ICEpush groups are kept alive only by the activity of each viewPushId.

Note that this would not retroactively add views, but retroactive adding is fundamentally incompatible with lazy push initialization, since early pages will be loaded that do not even participate in push notification.

(It's not obvious that there is a real use case for retroactive adding of views – most applications will have certain pages that require push and certain pages that do not. addCurrentSession() is used as a convenience so that push pages do not need to be accounted for individually, but addCurrentSession() would always be called when one of these pages is rendered, removing the need for retroactive addition of the page. If a page fragment dynamically required push to be supported, then addCurrentSession() would be called when the user interacted with that page causing the fragment to be updated, again requiring no retroactive addition.)

My understanding of how PushRederer.addCurrentSession() method should behave seems to be different. Currently when PushRederer.addCurrentSession() is called (with a certain group name) the implementation will make sure that any active view belonging to the current session is part of that group. In the future if a new view is created within the same session then that view is added as well to the group. Discarded views in the same session will be removed from the group.

If we don't want to keep track of the views then the implementation is significantly simplified but then the behavior of PushRederer.addCurrentSession() method will be highly misleading.

Modified SessionViewManager to not keep track of the active pushIds. New views are added to a session wide group only after PushRenderer.addCurrentSession method is called. Renamed also SessionViewManager methods to better reflect the new behavior.