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.

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

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

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

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

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