ICEfaces
  1. ICEfaces
  2. ICE-2900

dispose() no longer called on request scoped beans at correct time

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Invalid
    • Affects Version/s: 1.7RC1
    • Fix Version/s: 1.7
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces

      Description

      Basically request scoped beans are staying around after a full page refresh or a navigation rule execution. The "Text Enty" demo in Comp. Showcase uses an request scoped bean, type some text into it to update the backing bean. Then do a hard refresh of the browser of change the theme, the values are still here. This seems to be new behavior.
        
      By definition, our Request scoped beans should be getting reconstructed on full page refreshes or navigation redirects/forwards.

      I also see the request scoped persisting after the browser sends a <dispose-views> request. The procedure of opening a new View, doing some work, then disposing of the view will create a new Request scoped bean for each view, and while the View object is disposed of, the request scoped bean no longer is. If these request scoped beans add themselves to an IntervalRenderer or some such thing, the cleanup code using the disposableBeans interface no longer works, resulting in a growing collection of Renderables. Until the session expires.

        Activity

        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Assignee Priority P1
        Assignee Mircea Toma [ mircea.toma ]
        Mircea Toma made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Invalid [ 6 ]
        Ken Fyten made changes -
        Description From Patrick:

        Basically request scoped beans are staying around after a full page
        refresh or a navigation rule execution. The "Text Enty" demo uses an
        request scoped bean, type some text into it to update the backing bean.
        Then do a hard refresh of the browser of change the theme, the values
        are still here. This seems to be new behaviour.

        The Harcase guys are funning into the same problem on navigation rules.
        By definition, our Request scoped beans should be getting reconstructed
        on full page refreshes or navigation redirects/forwrads.

        I also see the request scoped persisting after the browser sends a <dispose-views> request. The RIM procedure of opening a new View, doing some work, then disposing of the view will create a new Request scoped bean for each view, and while the View object is disposed of, the request scoped bean no longer is. If these request scoped beans add themselves to an IntervalRenderer or some such thing, the cleanup code using the disposableBeans interface no longer works, resulting in a growing collection of Renderables.

        Until the session expires.
        Basically request scoped beans are staying around after a full page refresh or a navigation rule execution. The "Text Enty" demo in Comp. Showcase uses an request scoped bean, type some text into it to update the backing bean. Then do a hard refresh of the browser of change the theme, the values are still here. This seems to be new behavior.
          
        By definition, our Request scoped beans should be getting reconstructed on full page refreshes or navigation redirects/forwards.

        I also see the request scoped persisting after the browser sends a <dispose-views> request. The procedure of opening a new View, doing some work, then disposing of the view will create a new Request scoped bean for each view, and while the View object is disposed of, the request scoped bean no longer is. If these request scoped beans add themselves to an IntervalRenderer or some such thing, the cleanup code using the disposableBeans interface no longer works, resulting in a growing collection of Renderables. Until the session expires.

        Ken Fyten made changes -
        Field Original Value New Value
        Component/s Framework [ 10013 ]
        Fix Version/s 1.7 [ 10080 ]
        Assignee Priority P1
        Assignee Mircea Toma [ mircea.toma ]
        Priority Major [ 3 ] Critical [ 2 ]
        Greg Dick created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Greg Dick
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: