Subversion 19488
icefaces\component\src\com\icesoft\faces\component\paneltabset\PanelTabSet.java
Initial investigation showed that TabChangeListener instances were being continually added, on every lifecycle. Assuming the application class that implements that interface holds onto some memory, this would explain the memory leak. Since the test applications uses Facelets, the TabChangeListenerHandler was investigated, to see if it was the culprit, for adding the TabChangeListener instances. It was proven to not be the culprit, as it was only adding the initial instance, and not any of the subsequent ones. Then, the method responsible for adding listeners to the component was checked, in case the application, or something else, was adding them. This was shown to not be happening. Finally, the state saving and restoring mechanism was checked, since it had some suspicious looking code for adding listeners back. That proved to be the cause of the additions.
It was not exactly obvious how to change the state restoration code, since there turned out to be 3 different scenarios for state saving:
1. With JSF 1.1, state saving is not done, and the component tree and all listeners are left unchanged.
2. With some versions of JSF 1.2, our code keeps the component tree, but still calls the state saving and restoration code on them, allowing for misbehaving code to overgrow lists, as it adds new instances to old ones.
3. With other versions of JSF 1.2, our code removes the component tree, and starts fresh, so that the state restoration code only has new instances to add to the lists.
An integrated approach was found, to keep the optimisation of list re-use, for when the component tree was kept from before, yet not add duplicates.
Bug
Major
MODIFY
/icefaces/trunk/icefaces/component/src/com/icesoft/faces/component/paneltabset/PanelTabSet.java
Subversion 19488
icefaces\component\src\com\icesoft\faces\component\paneltabset\PanelTabSet.java
Initial investigation showed that TabChangeListener instances were being continually added, on every lifecycle. Assuming the application class that implements that interface holds onto some memory, this would explain the memory leak. Since the test applications uses Facelets, the TabChangeListenerHandler was investigated, to see if it was the culprit, for adding the TabChangeListener instances. It was proven to not be the culprit, as it was only adding the initial instance, and not any of the subsequent ones. Then, the method responsible for adding listeners to the component was checked, in case the application, or something else, was adding them. This was shown to not be happening. Finally, the state saving and restoring mechanism was checked, since it had some suspicious looking code for adding listeners back. That proved to be the cause of the additions.
It was not exactly obvious how to change the state restoration code, since there turned out to be 3 different scenarios for state saving:
1. With JSF 1.1, state saving is not done, and the component tree and all listeners are left unchanged.
2. With some versions of JSF 1.2, our code keeps the component tree, but still calls the state saving and restoration code on them, allowing for misbehaving code to overgrow lists, as it adds new instances to old ones.
3. With other versions of JSF 1.2, our code removes the component tree, and starts fresh, so that the state restoration code only has new instances to add to the lists.
An integrated approach was found, to keep the optimisation of list re-use, for when the component tree was kept from before, yet not add duplicates.