Table.getValue() on multi select sometimes returns [null]

This is not consistent, but sometimes when the value change listener on my Table gets triggered after I do a multi select, getValue() returns a collection with a single element in it: a null. This is also what is stored in event.getProperty().getValue(). I can clearly see in the UI that 3 rows have been selected. I expected getValue() to return a 3 element collection containing the model objects that are being rendered in the table.

Is this a known bug in the Table? I am using Vaadin 6.5.4. I haven’t seen anything in the release notes for subsequent versions to indicate this has been fixed.

Thanks,
David

anyone?

A little code snippets might increase your chance of getting a response.
You could try setNullSelectionAllowed(false); and make sure the table is set to be immediate.

Here’s what my code looks like to setup the table:

		inputs.setWidth(100, Sizeable.UNITS_PERCENTAGE);
		inputs.setHeight(100, Sizeable.UNITS_PERCENTAGE);
		inputs.setSelectable(true);
		inputs.setImmediate(true);
		inputs.setMultiSelect(true);
	  
		inputs.setNullSelectionAllowed(false);
		inputs.setColumnReorderingAllowed(true); 
		inputs.setColumnCollapsingAllowed(true);

Sorry, I can’t see any reason why this shouldn’t work. If you still have the same problem, make a simple testable case for the vaadin folks.

The above issues were with Vaadin 2.5.4. When I try to do multiselect of my table using Vaadin 2.3.4 (we have an older version of Vaadin on one of our repository branches for code in the field), I get the following null pointer exception. Notice that none of my code is in the stack:

java.lang.NullPointerException
at com.vaadin.ui.Table.getVisibleItemIds(Table.java:2808)
at com.vaadin.ui.AbstractSelect.changeVariables(AbstractSelect.java:426)
at com.vaadin.ui.Table.changeVariables(Table.java:1872)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.handleVariables(AbstractCommunicationManager.java:1087)
at com.vaadin.terminal.gwt.server.AbstractCommunicationManager.doHandleUidlRequest(AbstractCommunicationManager.java:587)
at com.vaadin.terminal.gwt.server.CommunicationManager.handleUidlRequest(CommunicationManager.java:265)
at com.vaadin.terminal.gwt.server.AbstractApplicationServlet.service(AbstractApplicationServlet.java:482)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:619)

Here is the line of code that results in the NPE:

    for (int i = 0; i < cells[CELL_ITEMID]

.length; i++) {

I guess this might be something that was fixed between 2.3.4 and 2.5.4?

I have noticed that when I do a shift multi-select, in the code for Table.handleSelectedItems(), it tries to look up the itemIds in the itemIdMapper based on the range value. What I found was that the ids in the itemIdMapper were out of sync with the range information. Here’s an example:

There are 4 rows in the table, with keys of 173-176. When I used shift-select to select 3 rows, the range value was “150-3”. However, there is no key of 150 in the itemIdMapper, so the lookup returns a null. Then, that null is passed to getItemIdsInRange with a startItemId of null and a length of 3. This results in a collection containing one null value, which is added to newValue. At the end of the method, setValue is called with [null]
. It seems like there could be some better null checking in this method.

How does the itemIdMapper get out of sync? I tried to find where that mapping is setup, but could not. The table itself displays 3 selected rows, and there are 4 valid items in the table, but as a result of the logic I described, getValue() returns [null]
(I.e. a collection with a single item of null). Note that I do not allow null selection for this table.

I can’t easily create a small testcase, because we have a very complex application, but I would appreciate some insight into how this data can get corrupted, and how we might possibly prevent that in our code. We really need a resolution to this, since we are shipping this product in 2 weeks.

Thanks in advance,
David

bump to the top

I have never heard of anything similar like this before. You could start with testing the latest version of Vaadin to see if that makes any difference to this. If not, you should create a minimal stand alone application where you can show this behavior, and create a ticket to
dev.vaadin.com
about it.

Hi

we are facing the same problem in Vaadin 6.7.5.
The problem occurs when refreshing the table container (using Container#removeAllItems and afterwards fill the container with new rows) and the selections are re-applied (in order to preserve the user’s selection).
We are making sure that the new selection contain only the SAME instances than the container (see also this thread: https://vaadin.com/forum/-/message_boards/view_message/1188989).
After the refresh and the re-applied selection the SHIFT-click doesn’t work anymore and leads to [null]
.

Best Regards
Udo Offermann