Assigning to Mircea, but this is not necessarily scheduled for ICEfaces 2.0.

Work on lazy Window Scope needs to be done before we can go back and look at the SessionExpiry exception strategy as the resource handlers for window scope and session monitoring are currently creating new sessions for each request due to the use of the ExternalContext.getSessionMap() method.

Need Assessment on feasibility and risk for implementing this for 2.0.1.

Ben has tested with the following "fix" to application.js:

namespace.setupBridge = function(setupID, viewID, windowID, configuration)

;

We have a few options:

• allow the above line of code to be turned off via configuration
  (thereby breaking WindowScope in a strange way)
• require WindowScope to be manually enabled
  (such as making the following required to be in the application faces-config.xml
  <el-resolver>org.icefaces.impl.application.WindowELResolver</el-resolver>
  and then detecting whether it is active or not; if not active, disposeWindow
  is not called)
• introduce different configurable strategies for WindowScope, such as using push
  or a cookie mechanism ("we don't know how to implement this, you decide")
• make WindowScope "lazy" so disposeWindow is not sent when the map is empty

Is the lazy approach possible? Disabling disposeWindow must be applied just prior to
the end of the body to allow any components on the page to make use of WindowScope,
but we are already applying this technique in the LazyPushManager.
If there is nothing in the window scope once the page is rendered, nothing can
be added from the outside (including WindowDisposed ViewScope beans). So, this
should simply be a matter of scanning the ViewMap for WindowDisposed beans and
checking whether the WindowScope map is empty. There should be no behavioural
changes caused by the lazy strategy. In the future, we can still add configuration
options for the window disposal strategy, but that can be decided later.

Unfortunately people will still be surprised if they use security filters and
WindowScope beans. To work towards that I think all we can do is refine the
cookie/push ideas described above.

Lazy looks like the best path ... any other comments or suggestions?

Implemented ICEfaces' side of lazy window scope feature. 'dispose-window' request is sent only when the window's scope map contains at least one bean. On each request the scope maps are checked for usage, the unused scope maps are discarded to avoid accumulating them. To avoid triggering exceptions when discarding early the unused maps introduced No-Op scope map used to replaced them.

Introduced 'org.icefaces.lazyWindowScope' context parameter used to disable lazy window scope feature when needed. Parameter's default value is 'true' thus enabling the lazy window scope feature by default.

The changes needed in ICEpush to handle lazy window scope gracefully are covered by issue PUSH-123 .

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.