ICEfaces
  1. ICEfaces
  2. ICE-3696

Test component field state saving

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8DR#1
    • Fix Version/s: 1.8DR#2, 1.8
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      All

      Description

      Similarly to ICE-3454, we want to test the component's saveState and restoreState functionality. But in this case, we want to simply look at every field that's non-static, non-final, and non-transient, give them all unique values, save and restore the components, and see if the fields still retain those values.

        Issue Links

          Activity

          Hide
          Mark Collette added a comment -

          Initially I implemented utility methods that use reflection, to do the state saving and restoration, which each of the components could use, so that adding or removing fields to/from a component would automatically result in the state saving doing the right thing. The problem was that the reflection code was noticeably slower than the hard coding approach. I tested several iterations of saving and restoring ice:commandButton 10,000 times. With hard coding it would usually take 0 milliseconds, and sometimes take 16 milliseconds. With reflection, the first few "lifecycles" of 10,000 iterations (where I'm simulating a component tree with 10,000 components), would take several hundred milliseconds. After, it would drop down to taking between 40 and 70 milliseconds. We deemed that too expensive in CPU time.

          Next, we explored the idea of generating code, for each component class, so that we'd have the best of automatic correctness and fast execution. The problem was that we'd complicate the build process noticeably. As well, it would complicate debugging, since you'd effectivel have two sets of source files and class files, which we thought would be a problem for our users.

          There was also the sub-option of code generation, which is class file modification, where we add state saving byte-codes to the class files, without intermediate source files. This still complicates things, and adds a certain degree of black magic, that could cause problems for users.

          So, the current solution is to write a solid test platform, to verify the hard coding. It's not as automatic, but is very straightforward, and gives the most flexibility with the greatest simplicity.

          Show
          Mark Collette added a comment - Initially I implemented utility methods that use reflection, to do the state saving and restoration, which each of the components could use, so that adding or removing fields to/from a component would automatically result in the state saving doing the right thing. The problem was that the reflection code was noticeably slower than the hard coding approach. I tested several iterations of saving and restoring ice:commandButton 10,000 times. With hard coding it would usually take 0 milliseconds, and sometimes take 16 milliseconds. With reflection, the first few "lifecycles" of 10,000 iterations (where I'm simulating a component tree with 10,000 components), would take several hundred milliseconds. After, it would drop down to taking between 40 and 70 milliseconds. We deemed that too expensive in CPU time. Next, we explored the idea of generating code, for each component class, so that we'd have the best of automatic correctness and fast execution. The problem was that we'd complicate the build process noticeably. As well, it would complicate debugging, since you'd effectivel have two sets of source files and class files, which we thought would be a problem for our users. There was also the sub-option of code generation, which is class file modification, where we add state saving byte-codes to the class files, without intermediate source files. This still complicates things, and adds a certain degree of black magic, that could cause problems for users. So, the current solution is to write a solid test platform, to verify the hard coding. It's not as automatic, but is very straightforward, and gives the most flexibility with the greatest simplicity.
          Hide
          Mark Collette added a comment -

          So far the testing has found changes for ICE-3666, as well as the need for ICE-3695. I've gotten the test to the point that there are probably some false failures, but it's not just tripping up on the reflection, and it's starting to report some actual failures. So I'm going to commit it so people can start fixing the failures in our components.

          TRUNK
          Subversion 17831
          icefaces\component\test\java\com\icesoft\faces\mock\test\CompPropsUtils.java
          icefaces\component\test\java\com\icesoft\faces\mock\test\TestDataProvider.java
          icefaces\component\test\java\com\icesoft\faces\mock\test\SerializedViewFieldTest.java
          icefaces\component\test\java\com\icesoft\faces\mock\test\data\MockMethodBinding.java

          Show
          Mark Collette added a comment - So far the testing has found changes for ICE-3666 , as well as the need for ICE-3695 . I've gotten the test to the point that there are probably some false failures, but it's not just tripping up on the reflection, and it's starting to report some actual failures. So I'm going to commit it so people can start fixing the failures in our components. TRUNK Subversion 17831 icefaces\component\test\java\com\icesoft\faces\mock\test\CompPropsUtils.java icefaces\component\test\java\com\icesoft\faces\mock\test\TestDataProvider.java icefaces\component\test\java\com\icesoft\faces\mock\test\SerializedViewFieldTest.java icefaces\component\test\java\com\icesoft\faces\mock\test\data\MockMethodBinding.java
          Hide
          Mark Collette added a comment -

          When the test fails, for now we don't want the build failing. Also, I made it stop reporting about deprecation, since it's highly redundant.

          TRUNK
          Subversion 17833
          icefaces\component\build.xml
          icefaces\component\test\java\com\icesoft\faces\mock\test\SerializedViewFieldTest.java

          Show
          Mark Collette added a comment - When the test fails, for now we don't want the build failing. Also, I made it stop reporting about deprecation, since it's highly redundant. TRUNK Subversion 17833 icefaces\component\build.xml icefaces\component\test\java\com\icesoft\faces\mock\test\SerializedViewFieldTest.java
          Hide
          Mark Collette added a comment -

          These are the main types of changes that were necessary for the test to pass:

          Component changes

          • Make component's saveState and restoreState handle a field
          • Mark fields that shouldn't be state saved transient, so the test will ignore them
          • Refactor fields, which are not state savable or Serializable (like other components in the tree, or data from the bean), but that aren't transient

          Object changes (Objects that the components refer to)

          • Make Serializable
          • Implement deep equals(Object), so that deserialized copies of objects can be compared to their originals

          Test changes

          • Create test object instances, covering all object types, of the component fields
          Show
          Mark Collette added a comment - These are the main types of changes that were necessary for the test to pass: Component changes Make component's saveState and restoreState handle a field Mark fields that shouldn't be state saved transient, so the test will ignore them Refactor fields, which are not state savable or Serializable (like other components in the tree, or data from the bean), but that aren't transient Object changes (Objects that the components refer to) Make Serializable Implement deep equals(Object), so that deserialized copies of objects can be compared to their originals Test changes Create test object instances, covering all object types, of the component fields
          Hide
          Mark Collette added a comment -

          Fixed a bug in the array comparison part of the test, which was counting String[] as not matching, when they actually did.

          TRUNK
          Subversion 17849
          icefaces\component\test\java\com\icesoft\faces\mock\test\SerializedViewFieldTest.java

          Show
          Mark Collette added a comment - Fixed a bug in the array comparison part of the test, which was counting String[] as not matching, when they actually did. TRUNK Subversion 17849 icefaces\component\test\java\com\icesoft\faces\mock\test\SerializedViewFieldTest.java
          Hide
          Mark Collette added a comment -

          The test has been tightened to let less through. By default a failure will now break the build.

          Subversion 18072
          icefaces\component\test\java\com\icesoft\faces\mock\test\SerializedViewFieldTest.java
          icefaces\component\test\java\com\icesoft\faces\mock\test\TestDataProvider.java
          Subversion 18073
          icefaces\component\test\java\com\icesoft\faces\mock\test\TestDataProvider.java

          Show
          Mark Collette added a comment - The test has been tightened to let less through. By default a failure will now break the build. Subversion 18072 icefaces\component\test\java\com\icesoft\faces\mock\test\SerializedViewFieldTest.java icefaces\component\test\java\com\icesoft\faces\mock\test\TestDataProvider.java Subversion 18073 icefaces\component\test\java\com\icesoft\faces\mock\test\TestDataProvider.java

            People

            • Assignee:
              Unassigned
              Reporter:
              Mark Collette
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: