Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.7.1
-
Component/s: None
-
Labels:None
-
Environment:ICEfaces, Ajax Push
-
Affects:Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial
Description
The current RenderManager API offers a high degree of control over server-initiated rendering, but provides more power than necessary for simple applications. The SessionRenderer provides a more basic API as follows:
public class org.icefaces.application.SessionRenderer extends java.lang.Object{
public static synchronized void addCurrentSession(java.lang.String groupName);
public static synchronized void removeCurrentSession(java.lang.String groupName);
public static void render(java.lang.String groupName);
}
A sample invocation, such as in the auctionMonitor would be
In a bean constructor:
SessionRenderer.addCurrentSession("auction");
When an event occurs:
SessionRenderer.render("auction");
The SessionRenderer is responsible for the maintenance of the lists of HttpSessions/PortletSessions. Lists of Views are obtained from the ICEfaces infrastructure. RenderingException is not passed to the application because, in this case, the application is only concerned with pushing updates to active users. If users are not active, they are automatically garbage collected.
public class org.icefaces.application.SessionRenderer extends java.lang.Object{
public static synchronized void addCurrentSession(java.lang.String groupName);
public static synchronized void removeCurrentSession(java.lang.String groupName);
public static void render(java.lang.String groupName);
}
A sample invocation, such as in the auctionMonitor would be
In a bean constructor:
SessionRenderer.addCurrentSession("auction");
When an event occurs:
SessionRenderer.render("auction");
The SessionRenderer is responsible for the maintenance of the lists of HttpSessions/PortletSessions. Lists of Views are obtained from the ICEfaces infrastructure. RenderingException is not passed to the application because, in this case, the application is only concerned with pushing updates to active users. If users are not active, they are automatically garbage collected.
Issue Links
- depends on
-
ICE-2742
Broadcast rendering API
-
- Closed
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Package-level JavaDoc Description has been added. Marking this one as FIXED again.
Show
Jack Van Ooststroom
added a comment - Package-level JavaDoc Description has been added. Marking this one as FIXED again.
Need to ensure this API is included in the ICEfaces JavaDoc, including the new org.icefaces.x package tree.
I checked in the following change:
- GroupAsyncRenderer
- Removed the add(HttpSession), contains(HttpSession) and remove(HttpSession) methods.
- Added the addCurrentSession(), containsCurrentSession() and removeCurrentSession() methods.
- Internally it stores the HttpSession and PortletSession instances via a WeakReference in its Set.
- SessionRenderer
- Changed the addCurrentSession(String), containsCurrentSession(String) and removeCurrentSession(String) methods to use the GroupAsyncRenderer's "equivalent" methods.
- SessionDispatcher
- Overloaded the getSingletonSessionServlet(HttpSession) method with the getSingletonSessionServlet(String sessionId) method.
This way HttpSession and PortletSession are not publically exposed in the API, nor is the JSF API exposed.
I successfully tested in both a servlet and portlet environment, and in both a non-clustered and clustered environment.
Marking this one as FIXED (which Ken already did 
Show
Jack Van Ooststroom
added a comment - I checked in the following change:
GroupAsyncRenderer
Removed the add(HttpSession), contains(HttpSession) and remove(HttpSession) methods.
Added the addCurrentSession(), containsCurrentSession() and removeCurrentSession() methods.
Internally it stores the HttpSession and PortletSession instances via a WeakReference in its Set.
SessionRenderer
Changed the addCurrentSession(String), containsCurrentSession(String) and removeCurrentSession(String) methods to use the GroupAsyncRenderer's "equivalent" methods.
SessionDispatcher
Overloaded the getSingletonSessionServlet(HttpSession) method with the getSingletonSessionServlet(String sessionId) method.
This way HttpSession and PortletSession are not publically exposed in the API, nor is the JSF API exposed.
I successfully tested in both a servlet and portlet environment, and in both a non-clustered and clustered environment.
Marking this one as FIXED (which Ken already did
HttpSession should not be part of the public API as it makes the servlet-api.jar a mandatory lib at compile time for applications using the RenderManager API. Reopening this one.
Show
Jack Van Ooststroom
added a comment - HttpSession should not be part of the public API as it makes the servlet-api.jar a mandatory lib at compile time for applications using the RenderManager API. Reopening this one.
Prototype implemented, pending checkin.
Show
Ted Goddard
added a comment - Prototype implemented, pending checkin.
updated auctionMonitor to use SessionRenderer for bid updates and chat messages. Ticking clocks still uses IntervalRenderer.
Note that auctionMonitor had an obsolete capability for propagating events between a stock JSF implementation and an ICEfaces implementation. This event feature has been deactivated to simplify the implementation.