This issue might have been fixed by the resolution of PUSH-30.

Will this feature also dynamically disable push when a view that was previously added to a render group is removed from the render group?

That's a good point. Push should be enabled on the page if the page is possible to update via push: in other words, the session is a member of a push group at the time the page is rendered. So, removing a session from all push groups, should result in push being disabled on that page.

Laziness report from examination of ICEfaces 2.0 "basic" demo including icepush.jar but using no push features:

page includes

<script src='code.icepush.jsf?a662406917' type='text/javascript'></script>

ice.push.register(['6564709390015864202:-7640438167776689860']

Blocking connection started:

POST /basic/listen.icepush.jsf HTTP/1.1

and is continually established with server-side heartbeat.

Non-ICEfaces page do not contain any ICEfaces or ICEpush references.

It is likely that the current session is a member of a render group for "session expired" notification, but this group should only be joined if push is otherwise used in the application, or "session expired" is explicitly configured (such as on the ice:config tag).

Full laziness should likely even omit the icepush javascript from the page, but this is worth discussion in the next core meeting.

Introduced LazyPushManager to keep track of views that are push enabled. The UIOutput responsible for rendering the ICEpush wiring will dynamically render the JS code only when a view is registered with PushRenderer. The view state key generated by BridgeSetup is now properly reused by PushRenderer to avoid a stack overflow.