ace:dataExporter does not work correctly when LazyDataModel is used with datatable, pagination and enabled selectedRowsOnly attribute.
There is at least 3 issues which I found with this mode.

1. Mixed order of exported data. (sequential selection of rows in the following order: 1st, 3rd & 5th will export them and arrange in a mixed order such us as 5th, 1st and 3rd).

2. Duplicated exported data. (selected rows will be repeated N times in the exported file. Where N is the number of pages in a lazy data table. This is similar to ICE-8297 but with selectedRowsOnly)

3. Corrupted export upon upon un-selection of current rows and selection of the new ones. (The data in exported file will show a mix of X previously and currently selected rows in a random order. The pattern will repeat itself N times. Here N is the number of pages in a lazy data table and X is a number of rows per page.)
In other words if you'd made the following selection initially: row 1,2,3 and 5 and then changed this selection to 10, 12 and 14 AND your data table show 5 rows per page. The outcome of the export will be represented with a mixed subset from the previous and current selection. This subset will contain a maximum of 5 data elements and it will repeat itself N times.

To reproduce 1 &2:
1. deploy attached source code with ICEfaces EE 3.0 P01 and poi-3.7.jar
2. Select a few rows from the table.
3. Click on "Export Selected Rows" button

.cvs file outcome attached.

was:
This is a follow up for the resolved ICE-8297.

ace:dataExporter does not work correctly when LazyDataModel is used with datatable, pagination and enabled selectedRowsOnly attribute.
There is at least 3 issues which I found with this mode.

1. Mixed order of exported data. (sequential selection of rows in the following order: 1st, 3rd & 5th will export them and arrange in a mixed order such us as 5th, 1st and 3rd).

2. Duplicated exported data. (selected rows will be repeated N times in the exported file. Where N is the number of pages in a lazy data table)

3. Corrupted export upon upon un-selection of current rows and selection of the new ones. (The data in exported file will show a mix of X previously and currently selected rows in the random order. The pattern will repeat itself N times. Here N is the number of pages in a lazy data table and X is a number of rows per page.)
In other words if you'd made the following selection initially: row 1,2,3 and 5 and then changed this selection to 10, 12 and 14 AND your data table show 5 rows per page. The outcome of the export will be represented with a mixed subset from the previous and current selection. This subset will contain a maximum of 5 data elements and it will repeat itself N times.

To reproduce 1 &2:
1. deploy attached source code with ICEfaces EE 3.0 P01 and poi-3.7.jar
2. Select a few rows from the table.
3. Click on "Export Selected Rows" button

.cvs file outcome attached.

Committed fix to trunk at revision 31068 (actually 'ICE-8297' was used in t=
he commit message).
The fix consists in retrieving the RowState object of each row on the page =
and checking if it's selected, instead of getting a list from RowStateMap o=
f all the rows that are selected.=20
Important note: the test case attached to this JIRA has many flaws: the dat=
a object, as well as the hashcode() and equals() methods do not follow the =
requirements to work with ace:dataTable. First of all, the hashcode() metho=
d doesn't seem to return a consistent number for the data contents. Since, =
when using lazy loading, we are actually creating new objects, their hash c=
odes have to match when they contain the same data. Otherwise, the RowState=
Map in the data table will create new entries instead of using a single ent=
ry for each row to keep the correct state information. Another flaw of the =
test case is that it creates a new Data() object every time a row data obje=
ct is created. This way, even if the hashcode() and equals() methods were c=
orrect, the date would be always different because of differences in millis=
econds, seconds, etc. If the 'birthday' property was always fixed, then the=
re wouldn't be any problem. I modified the row data object to return consis=
tent results for the hashcode() and equals() methods. It is attached to thi=
s issue for use when testing.
=20