Ted said:

"Session Attribute: org.icefaces.application.LazyPushManager

Maintains list of view keys (not viewID) for views making use of push.

When failover occurs, push group membership should automatically fail over.

If possible, ICEfaces should avoid duplicating JSF data structures (the table of view keys is a partial duplication of JSF state management)."

It is a duplication of IDs, that's all. The reason is reasonably well explained in http://jira.icefaces.org/browse/ICE-5594?focusedCommentId=28866&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_28866 comment.

"PushRenderer.addCurrentSession()

• set a Session attribute containing the PUSHID for the session. If this session attribute is detected during page rendering, add the ICEpush JavaScript to the page."

This strategy doesn't hold if PushRenderer.addCurrentSession is invoked a number of times and different from how many times PushRenderer.removeCurrentSession is called. That's the reason for the "noOfRegistrations" counter in LazyPushManager. Yes, the counter can be kept directly into the session, but implementation wise you end up with lots of session attributes that the different "managers" will use – global variable syndrome once again....which I hate.

"PushRenderer.addCurrentView()

• set a viewMap attribute containing the PUSHID for the view. If this view attribute is detected during page rendering, add the ICEpush JavaScript to the page."

The viewMap is not the right container since the viewIDs are actually 1-to-1 mapped to the view state keys. The view state keys represent the state of the different views currently active for a session.

In the end LazyPushManager could be merged with SessionViewManager, but really its functionality is orthogonal to the one of SessionViewManager.

All these objects need access to objects that can be constructed only locally, such as PushContext or ServletContext. The managers should be changed so that they won't keep references to instances of ServletContext and such, but they would receive them when their methods are invoked.
For example SessionViewManager.addView(String id) would be change to SessionViewManager.addView(String id, PushContext context) since the method uses internally PushContext class.
Also the fields of the managers can be saved into a serializable structure (without behavior) and that will be saved into the session (thus session scoped).
This approach will allow the creation of the managers at startup time, the context they would work in would be changed depending on what context instance it's passed in.

Refactored WindowScopeManager, SessionViewManager and LazyPushManager to save their serializable state in the session. Changed its methods to be stateless (and static), state is accessed and modified by these methods by looking it up from the session.

Created a separate issue for org.icefaces.push.DynamicResourceDispatcher refactoring since its resolution entails changes in the resource registration behavior: ICE-5848