Not sure why the older case was marked fixed.
This doesn't seem to be easy to replicate with our standard examples. As per the original customer comments, my theory was that the session had to be created and invalidated outside of most of the ICEfaces processing. Our SessionExpiredListener will still operate in this type of environment but the majority of the WindowScope processing will not meaning the appropriate "state" is never added to the session.
To mimic this behaviour, I simply changed the index.jsp of our basic example to:
<%
session.setAttribute("foo","bar");
session.invalidate();
response.sendRedirect("icefaces.jsf");
%>
Doing this creates a session and invalidates it before the WindowScopeManager has a chance to set things up. However, our SessionExpiredListener still runs so then you get the following logged:
Mar 20, 2013 10:11:39 AM org.icefaces.impl.application.SessionExpiredListener sessionDestroyed
WARNING: An exception occurred while trying to invoke @PreDestroy on window scoped beans: null
There are a couple of things we could do:
1) Since the log is at WARNING level, we could just turn this down as the involved code is basically already doing its job in catching the exception and moving on:
try {
WindowScopeManager.disposeWindows(session);
} catch (Exception exception) {
LOGGER.log(
Level.WARNING,
"An exception occurred while trying to invoke @PreDestroy on window scoped beans: " +
exception.getMessage());
}
2) Deal with the NullPointerException at the source as I originally suggested:
public static void disposeWindows(final HttpSession session) {
State state = (State) session.getAttribute(WindowScopeManager.class.getName());
if(state == null){
return;
}
notifyPreDestroyForAll(state.windowScopedMaps.values());
notifyPreDestroyForAll(state.disposedWindowScopedMaps);
}
For now I've opted for #2 and left the log level at WARNING as it may catch other behaviours we want to know about.
Not sure why the older case was marked fixed.
This doesn't seem to be easy to replicate with our standard examples. As per the original customer comments, my theory was that the session had to be created and invalidated outside of most of the ICEfaces processing. Our SessionExpiredListener will still operate in this type of environment but the majority of the WindowScope processing will not meaning the appropriate "state" is never added to the session.
To mimic this behaviour, I simply changed the index.jsp of our basic example to:
Doing this creates a session and invalidates it before the WindowScopeManager has a chance to set things up. However, our SessionExpiredListener still runs so then you get the following logged:
There are a couple of things we could do:
1) Since the log is at WARNING level, we could just turn this down as the involved code is basically already doing its job in catching the exception and moving on:
2) Deal with the NullPointerException at the source as I originally suggested:
For now I've opted for #2 and left the log level at WARNING as it may catch other behaviours we want to know about.