Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: Uncategorized
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      340
    • Status Whiteboard:
      Hide

      EGEasy5 effort_moderate

      Show
      EGEasy5 effort_moderate

      Description

      Background: In the portlet environment the Faces lifecyle spans 2 requests
      (portletAction and portletRender). Typically this means the FacesContext is
      destroyed at the end of the action phase and re-established in the render.
      Because of this the bridge needs some way of preserving the view so that it too
      can be restored in the render. Currently, the only way to have Faces save the
      view is to render it. One is not able to render during a portlet action. To
      get around this, the bridge currently caches the current view in memory and
      manually reinsert it on the first render following an action (after that because
      we are rendering it relies on Faces to save/resttore the view).

      Need: To be able to use the Faces state manager to save the view at the end of
      an action.

        Activity

        Hide
        kito75 added a comment -

        Michael, since we're updating state management, is this something we should push
        for 2.0/2.1?

        Show
        kito75 added a comment - Michael, since we're updating state management, is this something we should push for 2.0/2.1?
        Hide
        rogerk added a comment -

        whiteboard

        Show
        rogerk added a comment - whiteboard
        Hide
        Ed Burns added a comment -

        Pushed to 2.1

        Show
        Ed Burns added a comment - Pushed to 2.1
        Hide
        Ed Burns added a comment -

        Prepare to delete "spec" subcomponent.

        Show
        Ed Burns added a comment - Prepare to delete "spec" subcomponent.
        Hide
        Ed Burns added a comment -

        Move these to unscheduled because we need to target them correctly. 2.next isn't
        specific enough.

        Show
        Ed Burns added a comment - Move these to unscheduled because we need to target them correctly. 2.next isn't specific enough.
        Hide
        Ed Burns added a comment -

        The decision of when to commence state saving is internal to the ViewHandler.
        Can you achieve your requirement by decorating ViewHandler?

        Show
        Ed Burns added a comment - The decision of when to commence state saving is internal to the ViewHandler. Can you achieve your requirement by decorating ViewHandler?
        Hide
        Manfred Riem added a comment -

        Closing resolved issue out

        Show
        Manfred Riem added a comment - Closing resolved issue out

          People

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

            Dates

            • Created:
              Updated:
              Resolved: