Looks like the actionListener is getting called properly and that the list of items is properly reset during INVOKE_APPLICATION phase. However, when I dump out the contents of the old and new DOM during the diff, the extra row items that were added are still in there. My suspicion is that there is a state-saving subtlety involved here.

Removing the saveState and restoreState logic from DataTable seems to do the trick. It was the "old" JSF 1.x style state saving. Instead we defer to the UIData parent class to do it the modern way.

I ran through the datatable on both Mojarra and MyFaces and didn't seen any obvious side-effects from removing the code. On the plus side, it also seems to have fixed http://jira.icefaces.org/browse/ICE-7560.

Had to revert, since we do need to store that info. Will reassess how this might have to be adapted to work with MyFaces.

icefaces 3
Subversion 26842

saveState changes had to be reverted for now.

State saving fixes in r26879 didn't resolve this issue, likely the original fix to caching resulted in table state reevaluating and covering up the cause of this bug, so I'm detaching it from that issue for further analysis.

r26883 - Fixed MyFaces table + other component out of sync interaction. MyFaces appears to generate the DataModel for the DataTable lifecycle before the feature being used in this issue has a chance to alter the backing List of the DataTable. Since the DataModel is cached for the life of the component (as was derived from the Mojarra behaviour for getDataModel) we must regenerate the dataModel prerender to catch the changes that have been made. This is required in Mojarra when the DataTable has altered its own backing List during the lifecycle, for example in filtering. The autofiltering the table attempts during its first render is responsible for the state saving change Deryk originally made fixing the issue by continually attempting a filter, and thus regenerating the model.