MyFaces Core
  1. MyFaces Core
  2. MYFACES-2754

MyFaces can attempt to create a new session after the response has been committed

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.2.9, 2.0.0
    • Fix Version/s: 2.0.1
    • Component/s: General
    • Labels:
      None

      Description

      As currently implemented, MyFaces can attempt to create a new session after the response has been committed. This is due to calling saveSerializedView on the JspStateManagerImpl even in cases where writeState was never called (e.g. a JSP outcome target with no form tags). This can lead to either an IllegalStateException being thrown or else extra sessions being created which wait until the session timeout is reached to be destroyed and thus can lead to a potential memory leak. Which behavior is seen depends on the appserver being used and whether it reuses session cookies for the same client.

      JSPStateManagerImpl will be updated to set a FacesContext attribute on writeState to indicate that the state should be written by saveSerializedView.

      On 2.0, FlashImpl also needs to be updated as well to not create a new session during the remove children operation. Currently we are creating a new session just to create a new map and then clear it.

        Activity

        Michael Concini created issue -
        Hide
        Michael Concini added a comment -

        initial fix breaks client side state saving in some instances. retesting with a slight change that should resolve it. Will commit the change this afternoon once full testing is completed.

        Show
        Michael Concini added a comment - initial fix breaks client side state saving in some instances. retesting with a slight change that should resolve it. Will commit the change this afternoon once full testing is completed.
        Michael Concini made changes -
        Field Original Value New Value
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 2.0.1 [ 12315117 ]
        Resolution Fixed [ 1 ]
        Hide
        Leonardo Uribe added a comment -

        The changes committed here changes the default behavior of saveSerializedView. It suppose we have the right ViewHandler in place for JspStateManagerImpl, but sometimes (TCK tests, custom state manager or view handler, .....) this is not necessary true. So, we need to indicate in some way the current ViewHandler "matches" with the state manager. The solution is add a variable that only evaluate isWritingState if it was activated the "match" when it was called ViewHandler.initView().

        Show
        Leonardo Uribe added a comment - The changes committed here changes the default behavior of saveSerializedView. It suppose we have the right ViewHandler in place for JspStateManagerImpl, but sometimes (TCK tests, custom state manager or view handler, .....) this is not necessary true. So, we need to indicate in some way the current ViewHandler "matches" with the state manager. The solution is add a variable that only evaluate isWritingState if it was activated the "match" when it was called ViewHandler.initView().
        Leonardo Uribe made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Leonardo Uribe made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Leonardo Uribe made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Hide
        Leonardo Uribe added a comment -

        The changes done in this patch causes full state saving fails. When it is used server side state saving things seem to work, but when a postback is sent, it is notice there is no state and a ViewExpiredException is thrown.

        I have to revert the changes done related to StateManager and ViewHandler. I'll attach the changes in a patch, to be studied later

        Show
        Leonardo Uribe added a comment - The changes done in this patch causes full state saving fails. When it is used server side state saving things seem to work, but when a postback is sent, it is notice there is no state and a ViewExpiredException is thrown. I have to revert the changes done related to StateManager and ViewHandler. I'll attach the changes in a patch, to be studied later
        Leonardo Uribe made changes -
        Resolution Fixed [ 1 ]
        Status Closed [ 6 ] Reopened [ 4 ]
        Leonardo Uribe made changes -
        Attachment MYFACES-2754-reverted-code.patch [ 12450066 ]

          People

          • Assignee:
            Michael Concini
            Reporter:
            Michael Concini
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development