javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-143

input request ignored after repeated use of one view

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1_01
    • Fix Version/s: 1.0
    • Component/s: None
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      143

      Description

      When repeatedly issuing requests from the same view, the
      NUMBER_OF_VIEWS_IN_SESSION value is exceeded, even if only one or two views are
      actually stored in session. When this occurs, the current view is deleted, the
      input parameters are ignored, and the designated action method is not invoked.

      StateManagerImpl displays the following: "message Number of views in session
      exceeded specified number [NUMBER_OF_VIEWS_IN_SESSION]". This occurs only if
      javax.faces.STATE_SAVING_METHOD is set to server.

      StateManagerImpl then removes the current view from session and creates a new
      instance of the current view. Any parameters on the incoming request are not
      posted to the current view. The action associated with the current request is
      not invoked.

      By dumping out the values of ExternalContext.sessionMap, it does not appear that
      the actual number of views in session ever exceeds NUMBER_OF_VIEWS_IN_SESSION.
      But the number of values in com.sun.faces.VIEW_LIST (also stored in session)
      grows to equal NUMBER_OF_VIEWS_IN_SESSION because it contains duplicate entries
      for the same view.

      Here's an example of the contents of sessionMap (NUMBER_OF_VIEWS_IN_SESSION was
      set to 4 to analyze this problem):

      (StateManagerImpl.java:200)==>Restoring view from session for viewId
      /pages/SalesDirectoryHomePage.jsp
      (StateManagerImpl.java:256)==>Number of views in session exceeded specified
      number 4.Removing view /pages/SalesDirectoryHomePage.jsp
      ...
      session #1 key=/pages/SalesSearchResultsPage.jsp
      value=javax.faces.component.UIViewRoot@20224a
      session #2 key=javax.faces.request.charset value=ISO-8859-1
      session #3 key=com.sun.faces.VIEW_LIST value=[/pages/SalesSearchResultsPage.jsp,
      /pages/SalesSearchResultsPage.jsp, /pages/SalesSearchResultsPage.jsp,
      /pages/SalesSearchResultsPage.jsp]
      ...
      (ViewHandlerImpl.java:275)==>Created new view for
      /pages/SalesSearchResultsPage.faces

      Note that view /pages/SalesDirectoryHomePage.jsp has already been removed from
      session and com.sun.faces.VIEW_LIST when session was dumped. Is there a reason
      why /pages/SalesSearchResultsPage.jsp must be stored in com.sun.faces.VIEW_LIST
      multiple times (even though only one SalesSearchResultsPage.jsp appears in session)?

      A logical fix is to not add a view to com.sun.faces.VIEW_LIST if that view is
      already contained in that list. However, even if this were fixed,
      StateManagerImpl should never remove the current view from session before
      processing it (since the current view may already be one of the views stored in
      session). The current request should always be processed. Perhaps one or more
      views can be removed from session before the current view is saved to session.

      Three possible enhancements:
      (1) provide a removeStoredView(String viewid) method in ExternalContext to
      enable the application to remove a view from session.
      (2) provide a getStoredViewids() method in ExternalContext to enable the
      application to easily identify the viewIds stored in session.
      (3) provide an event handler for the application to handle a
      NUMBER_OF_VIEWS_IN_SESSION-exceeded event (the application handle would use
      enhancements #1 & #2 above to allow the application to override the default
      behavior).

        Activity

        Hide
        staskor added a comment -

        This can be closed; the problems identified in this request were encountered in
        version 1.1 and have been fixed in version 1.1_01 of the reference
        implementation.

        Show
        staskor added a comment - This can be closed; the problems identified in this request were encountered in version 1.1 and have been fixed in version 1.1_01 of the reference implementation.
        Hide
        Ed Burns added a comment -

        Marking closed per analysis and user feedback.

        Show
        Ed Burns added a comment - Marking closed per analysis and user feedback.
        Hide
        Manfred Riem added a comment -

        Closing issue out

        Show
        Manfred Riem added a comment - Closing issue out

          People

          • Assignee:
            javaserverfowner
            Reporter:
            staskor
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: