Details
Bug
Major
Description
"Accessing attributes via this Map must cause the creation of a session associated with the current request, if such a session does not already exist."
The spec also notes that the proper way to ensure that a session is already available is to call ExternalContext.getSession(false) before calling getSessionMap(). According to code at the time when this JIRA was created, the getSessionMap() method is used in the following places of the core framework:
core (6 usages)
org.icefaces.application (1 usage)
ResourceRegistry (1 usage)
addSessionResource(Resource) (1 usage)
(188, 39) .getExternalContext().getSessionMap(), resource );
org.icefaces.impl.application (3 usages)
LazyPushManager (1 usage)
getState(FacesContext) (1 usage)
(85, 55) Map sessionMap = context.getExternalContext().getSessionMap();
SessionTimeoutMonitor (1 usage)
isResourceRequest(FacesContext) (1 usage)
(50, 42) Map sessionMap = externalContext.getSessionMap();
WindowScopeManager (1 usage)
getState(FacesContext) (1 usage)
(311, 42) Map sessionMap = externalContext.getSessionMap();
org.icefaces.impl.push (1 usage)
SessionViewManager (1 usage)
getState(FacesContext) (1 usage)
(89, 55) Map sessionMap = context.getExternalContext().getSessionMap();
org.icefaces.impl.util (1 usage)
CharacterEncodingHandler (1 usage)
calculateCharacterEncoding(FacesContext) (1 usage)
(118, 47) charEnc = (String) extContext.getSessionMap().get(ViewHandler.CHARACTER_ENCODING_KEY);
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Verifying session's validity every time ExternalContext.getSessionMap method is called has been a failed experiment. In most of the cases it is not clear what is action that needs to be taken when session is invalid: throw an exception, return silently or return some value. Also, it's not clear at which point (in the code) the session is created the first time thus it wasn't easy to decide when to create or avoid creating a new session.
Instead there's code introduced in the resource handler that is invoked the first time (SessionTimeoutMonitor) that creates new sessions only during page load requests. When session is invalid or expired during an AJAX request SessionTimeoutMonitor will block the other resource handlers from executing and force a JSF lifecycle which will result into a ViewExpiredException eventually re-casted in a SessionExpiredException by our exception handler.
This could potentially interfere with 3rd party ResourceHandlers that do not require a Session: once the Session is found to be invalid, all ResourceHandling would be stopped.
There are some usages in the components but I assume that they are fine to use as they shouldn't be called if the session has truly expired. This may also be true of some of the usages in the core as well.