javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-2146

ViewExpiredException not thrown with client state saving method

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Incomplete
    • Affects Version/s: 2.0.2, 2.0.4
    • Fix Version/s: None
    • Component/s: state saving
    • Labels:
      None

      Description

      I set com.sun.faces.clientStateTimeout to 30 (sec.) and session-timeout to 1 (min.). Then, I start my application and wait a few minutes and try to do some action on my application so that the lifecycle is invoked again. Such trial shows that:

      1) ViewExpiredException is not thrown.
      2) When javax.faces.STATE_SAVING_METHOD to "client" view handler's restoreView method returns non-null object while null is returned when javax.faces.STATE_SAVING_METHOD is set to "server".

      This is somehow misleading if I try to catch time-out with client state saving method (the workaround for server state saving method is wrapping the view handler, and testing whether restoreView method returns null).

      Regards,

        Activity

        Hide
        pablo53 added a comment -

        According to http://wikis.sun.com/display/GlassFish/JavaServerFacesR:

        com.sun.faces.clientStateTimeout: This specifies the maximum time (in seconds) that client state will be considered valid by the default StateManager/ResponseStateManager implementations. If the time between requests exceeds the configured time, a javax.faces.application.ViewExpiredException. will be thrown. It is important to note that if this feature is enabled, and client requests are recieved with view state produced from a previous version, the ViewExpiredException will be thrown immediately.

        See: IN SECONDS!

        However, com.sun.faces.renderkit.ClientSideStateHelper.hasExpired() is as follows:

        protected boolean hasStateExpired(long stateTime) {

        if (stateTimeoutEnabled)

        { long elapsed = (System.currentTimeMillis() - stateTime) / 60000; return (elapsed > stateTimeout); }

        else

        { return false; }

        }

        Dividing milliseconds by 60000 means that the expiration time is expressed in MINUTES not SECONDS.

        This is what confused me so much...

        Show
        pablo53 added a comment - According to http://wikis.sun.com/display/GlassFish/JavaServerFacesR: com.sun.faces.clientStateTimeout: This specifies the maximum time (in seconds) that client state will be considered valid by the default StateManager/ResponseStateManager implementations. If the time between requests exceeds the configured time, a javax.faces.application.ViewExpiredException. will be thrown. It is important to note that if this feature is enabled, and client requests are recieved with view state produced from a previous version, the ViewExpiredException will be thrown immediately. See: IN SECONDS! However, com.sun.faces.renderkit.ClientSideStateHelper.hasExpired() is as follows: protected boolean hasStateExpired(long stateTime) { if (stateTimeoutEnabled) { long elapsed = (System.currentTimeMillis() - stateTime) / 60000; return (elapsed > stateTimeout); } else { return false; } } Dividing milliseconds by 60000 means that the expiration time is expressed in MINUTES not SECONDS. This is what confused me so much...
        Hide
        Manfred Riem added a comment -

        Can you please try this on a more recent 2.1 version?

        Show
        Manfred Riem added a comment - Can you please try this on a more recent 2.1 version?
        Hide
        Manfred Riem added a comment -

        Lowering priority because of no response.

        Show
        Manfred Riem added a comment - Lowering priority because of no response.
        Hide
        Manfred Riem added a comment -

        Lowering priority because of no response

        Show
        Manfred Riem added a comment - Lowering priority because of no response
        Hide
        Manfred Riem added a comment -

        Closing issue because of inactivity

        Show
        Manfred Riem added a comment - Closing issue because of inactivity

          People

          • Assignee:
            Unassigned
            Reporter:
            pablo53
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: