javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-1716

StateSaverHolder and Objects not implementing StateHolder nor Serializable State

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.2
    • Fix Version/s: None
    • Component/s: state saving
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      1,716
    • Status Whiteboard:
      Hide

      size_medium importance_medium

      Show
      size_medium importance_medium

      Activity

      Hide
      rogerk added a comment -

      triage

      Show
      rogerk added a comment - triage
      Hide
      hanafey added a comment -

      Any further comments??

      Show
      hanafey added a comment - Any further comments??
      Hide
      rogerk added a comment -

      triage

      Show
      rogerk added a comment - triage
      Hide
      Adrian Gygax added a comment - - edited

      Attached a small Eclipse project containing a testcase demostrating the problem and a patched StateHolderSaver which fixes the bug.

      The problem is in the constructor of StateHolderSaver which doesn't handle the case of a not serializable class correctly. StateHolderSaver.restore specifies, that for a class which is not serializable "className" and "savedState" are both expected to be null. However the constructor also sets the className if a class is not serializable:

          public StateHolderSaver(FacesContext context, Object toSave) {
      
              className = toSave.getClass().getName();
              
              if (toSave instanceof StateHolder) {
                  //...
              } else if (toSave instanceof Serializable) {
                  savedState = (Serializable) toSave;
                  className = null;
              }
          }
      

      My recommended fix is to move the className initialization into the "if instance of StateHolder" block, because this is the only case where "className" is expected to have a non-null value:

          public StateHolderSaver(FacesContext context, Object toSave) {
              
              if (toSave instanceof StateHolder) {
                  className = toSave.getClass().getName();
                  //...
              } else if (toSave instanceof Serializable) {
                  savedState = (Serializable) toSave;
              }
          }
      
      Show
      Adrian Gygax added a comment - - edited Attached a small Eclipse project containing a testcase demostrating the problem and a patched StateHolderSaver which fixes the bug. The problem is in the constructor of StateHolderSaver which doesn't handle the case of a not serializable class correctly. StateHolderSaver.restore specifies, that for a class which is not serializable "className" and "savedState" are both expected to be null. However the constructor also sets the className if a class is not serializable: public StateHolderSaver(FacesContext context, Object toSave) { className = toSave.getClass().getName(); if (toSave instanceof StateHolder) { //... } else if (toSave instanceof Serializable) { savedState = (Serializable) toSave; className = null ; } } My recommended fix is to move the className initialization into the "if instance of StateHolder" block, because this is the only case where "className" is expected to have a non-null value: public StateHolderSaver(FacesContext context, Object toSave) { if (toSave instanceof StateHolder) { className = toSave.getClass().getName(); //... } else if (toSave instanceof Serializable) { savedState = (Serializable) toSave; } }
      Hide
      Manfred Riem added a comment -

      Looking at the code for StateHolderSaver on trunk shows me that the className is used by the restore method. Even in the case the submitter asserts it is not. So I am closing this as "Won't fix" since the restore method requires the className to be available during restore.

      Show
      Manfred Riem added a comment - Looking at the code for StateHolderSaver on trunk shows me that the className is used by the restore method. Even in the case the submitter asserts it is not. So I am closing this as "Won't fix" since the restore method requires the className to be available during restore.

        People

        • Assignee:
          Unassigned
          Reporter:
          hanafey
        • Votes:
          3 Vote for this issue
          Watchers:
          2 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved: