MyFaces Trinidad
  1. MyFaces Trinidad
  2. TRINIDAD-798

StateManagerImpl extends StateManager rather then StateManagerWrapper

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.3-core
    • Fix Version/s: 1.0.6-core, 1.2.6-core
    • Component/s: Portlet
    • Labels:
      None
    • Environment:
      JSR-168

      Description

      In JSF 1.1, there was no StageManagerWrapper provided by JSF so we were extending the base StateManager. In 1.2 this class was provided in order to support the delegation chain. This delegation chain is important to support the JSR-301's portlet bridge.

      Trinidad's StateManagerImpl should be changed to extend JSF1.2's StateManagerWrapper class in order to support this delegation chain. The mechanism used in 1.1 is not sufficient for 1.2 extensions which may require a StateManager.

        Activity

        Hide
        Scott O'Bryan added a comment -

        This is a 1.2.x Trinidad fix only. It cannot be backported to Trinidad 1.0.x.

        Show
        Scott O'Bryan added a comment - This is a 1.2.x Trinidad fix only. It cannot be backported to Trinidad 1.0.x.
        Hide
        Scott O'Bryan added a comment -

        Patch to fix this issue. It will need to be applied to the 1.2.4 branch when created...

        Show
        Scott O'Bryan added a comment - Patch to fix this issue. It will need to be applied to the 1.2.4 branch when created...
        Hide
        Scott O'Bryan added a comment -

        I added this patch to the Trinidad 1.2.3.1-branch for testing in the portal environment. It will need to be applied to the 1.2.4 branch was well.

        Show
        Scott O'Bryan added a comment - I added this patch to the Trinidad 1.2.3.1-branch for testing in the portal environment. It will need to be applied to the 1.2.4 branch was well.
        Hide
        Matthias Weßendorf added a comment -

        scotty,

        I see some related commits, but issue is still open

        Show
        Matthias Weßendorf added a comment - scotty, I see some related commits, but issue is still open
        Hide
        Scott O'Bryan added a comment -

        In the 1.1 branch, I did some minor restructuring of the StateManagerImpl to allow for JSF 1.1 and JSF 1.2 implementations to be somewhat consistent. Basically I needed to make the original saveSerializedView method private and then implement a new public saveSerializedView method which calls into it. This was done so that we could change to the new API's in the 1.2 branch while still keeping the same base implementation.

        In the 1.2 branch, I took the modifications made to 1.1 and implemented and extended StateManagerWrapper. I removed the new saveSerializedView method and implemented a saveView method which calls into the private saveSerializedView method. When the SerializedView is returned, I create an object array, saving the SerializedView's structure and state in it. Returning the data in this format allows us to use the same CoreRequestStateManager in both implementations and no other modification is necessary.

        Show
        Scott O'Bryan added a comment - In the 1.1 branch, I did some minor restructuring of the StateManagerImpl to allow for JSF 1.1 and JSF 1.2 implementations to be somewhat consistent. Basically I needed to make the original saveSerializedView method private and then implement a new public saveSerializedView method which calls into it. This was done so that we could change to the new API's in the 1.2 branch while still keeping the same base implementation. In the 1.2 branch, I took the modifications made to 1.1 and implemented and extended StateManagerWrapper. I removed the new saveSerializedView method and implemented a saveView method which calls into the private saveSerializedView method. When the SerializedView is returned, I create an object array, saving the SerializedView's structure and state in it. Returning the data in this format allows us to use the same CoreRequestStateManager in both implementations and no other modification is necessary.

          People

          • Assignee:
            Scott O'Bryan
            Reporter:
            Scott O'Bryan
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development