Issue still reproducible with IF4 trunk rev# 39869/ EE-3.3.0-maintenance branch rev# 39821.

After some extensive investigation, it was found that the root of the problem is in the Mojarra version used by the 3.3 EE maintenance branch.

First of all, the problem has nothing to do with the FilterOptions attribute. Second, using strings for this attribute is invalid, as the TLD documentation for this attribute states that it "Defines a collection of SelectItem objects for use as filter choices." This is already corrected in the test app, but specifying a filter still doesn't work.

Moreover, this problem doesn't occur in the 4.0 trunk, and it doesn't occur in the 3.3 EE branch when using MyFaces.

After investigating the various methods in our code that handle filtering in the 3.3 EE maintenance branch (which happen to be identical to those of the 4.0 trunk), it was found that when specifying a filter, the filter value is never set properly in the column component nor in the FilterState object. In the end, the cause of this behaviour is that the DataTable.getColumns() method is returning twice the number of column components in the table. So, if a table has 8 columns, this method will return a list of 16 Column objects. So, the state of the different columns is being lost or doesn't match the right column. These 16 column objects have different hash codes and different object signatures, so it's not possible to implement a quick fix that simply checks for repeated objects.

The root cause of this behaviour doesn't seem to be in our code; it starts when calling datatable.getChildren() (which we do not override in the DataTable class nor in the generator). The first time it's called, it returns twice the number of columns in the table. Subsequent invocations of this method return the actual number of columns in the table, but the state of the table and columns, in regards to filtering, is already corrupted and the filtering functionality doesn't work. As stated above, this seems to be a problem with the Mojarra version used in the 3.3 EE maintenance branch, since this problem doesn't happen in the 4.0 trunk. Moreover, the code that handles filtering is identical in the 3.3 EE maintenance branch and the 4.0 trunk. The problem doesn't happen either in the 3.3 EE maintenance branch when using MyFaces.

Assign to Mircea to further analyze Art's findings, re:

he root cause of this behaviour doesn't seem to be in our code; it starts when calling datatable.getChildren() (which we do not override in the DataTable class nor in the generator). The first time it's called, it returns twice the number of columns in the table. Subsequent invocations of this method return the actual number of columns in the table, but the state of the table and columns, in regards to filtering, is already corrupted and the filtering functionality doesn't work. As stated above, this seems to be a problem with the Mojarra version used in the 3.3 EE maintenance branch, since this problem doesn't happen in the 4.0 trunk. Moreover, the code that handles filtering is identical in the 3.3 EE maintenance branch and the 4.0 trunk. The problem doesn't happen either in the 3.3 EE maintenance branch when using MyFaces.

Some more details...

It's important to clarify that when getChildren() returns twice the number of columns in the table is only during the first request. It's not just the first time the method is called; it's during the whole lifescyle. This doesn't occur the first time the page is rendered nor at the second and subsequent requests.

I found out that the showcase filtering demo doesn't have this issue. It seems that the problem in the test app is because of the use of the 'binding' attribute in the table. If this attribute is removed, then everything works normally.

Modified DataTable.getFilterMap method to not cache its calculated results, since the results can change during the lifetime of the component instance.
When data table binding is used the component instance is not recreated during component tree building causing the table to run with old filtering state.

Confirmed fixed Icefaces 4 trunk, Icefaces ee-3.3.0 maintenance branch r40839. Tomcat 7, all browsers.