ICEfaces
  1. ICEfaces
  2. ICE-9071

SessionExpired WARNING An exception occurred while trying to invoke @PreDestroy on window scoped beans: null

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-3.0.0.GA_P01, EE-3.2.0.GA
    • Fix Version/s: 3.3
    • Component/s: Bridge, Framework
    • Labels:
      None
    • Environment:
      Websphere, Weblogic
    • Assignee Priority:
      P2
    • Salesforce Case Reference:

      Description

      The following warning message can be shown many times in the sever logs:

      SessionExpired WARNING An exception occurred while trying to invoke @PreDestroy on window scoped beans: null

      This is being reported to occur when a users session has timed out. There are no Windows scoped beans being used nor is the @PreDestroy annotaton being used. The warning doesn't have any functional impact but can clog up the server logs depending on the user load.

        Activity

        Hide
        Deryk Sinotte added a comment -

        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 {
            // Not everything might be available to us anymore from the session, causing a possible exception.
            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) {
            // The strategy is to invoke @PreDestroy on as many applicable window scoped beans as possible and not to bail
            // out on the first fail.
            State state = (State) session.getAttribute(WindowScopeManager.class.getName());
        
            //ICE-9071: It's possible for a session to expire without a WindowScopeManager if the session was created and
            //invalidated without the WindowScopeManager doing it's thing (i.e. no JSF lifecycle).
            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.

        Show
        Deryk Sinotte added a comment - 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 { // Not everything might be available to us anymore from the session, causing a possible exception. 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) { // The strategy is to invoke @PreDestroy on as many applicable window scoped beans as possible and not to bail // out on the first fail. State state = (State) session.getAttribute(WindowScopeManager.class.getName()); //ICE-9071: It's possible for a session to expire without a WindowScopeManager if the session was created and //invalidated without the WindowScopeManager doing it's thing (i.e. no JSF lifecycle). 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.

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Arran Mccullough
          • Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: