Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0-Alpha3
-
Fix Version/s: 2.0-Alpha3, 2.0.0
-
Component/s: Framework
-
Labels:None
-
Environment:ICEfaces 2.0
Description
The PushRenderer implementation currently makes use of persistent references to session objects. This is problematic for two reasons: it may be running in a Portlet context and the Session object may not be valid outside of the HTTP request serving the session. Even though a "Session" may be the object of interest to the application developer, the implementation needs to work directly with the underlying objects associated with the push connections.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Deryk has fixed this for ICEfaces 1.8:
http://jira.icefaces.org/browse/ICE-4621
However the underlying infrastructure is different (again indicating that this should be fixed as part of the notification service implementation).
The notification service strategy is outlined in the wiki:
http://wiki.icefaces.org/display/facesDev/Ajax+Push+Architecture
Assigning to Mircea. Ted to add comments regarding the current implementation.
Their should be a direct correspondence between ICEfaces groups and ICEpush groups. Likely we need to add a SUBID that corresponds to notification of all browser windows to ICEpush.
First step taken in fixing this issue was to change the assumption that a window will contain only one view. SessionViewManager was introduced to register and keep track of all the views created within a session. Once this achieved PushRenderer was changed to make use of SessionViewManager and PushContext. This way the groups managed by PushRenderer are in reality ICEpush groups.
PushRenderer.addCurrentView and PushRenderer.removeCurrentView are also implemented by making use of SessionViewManager in conjunction with current FacesContext.
The JSF view state identifiers are reused as puhIds for the views.
Also introduced PortableRenderer to allow for render notifications to be sent when FacesContext is not present. PortableRenderer can be looked up at application startup.
It may be desirable to delay this work to be done as part of the notification service implementation.