Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
Indexed container with Tables
I have a lazily loading indexed container that is used inside a table.
My indexed container (let's call it ObjectContainer) extends ITK's own IndexedContainer. The functionality is the following in a nutshell: The container contains only a small amount of items (a cache for database contents). When an item is requested of the container that is not inside the current cache area, the current contents are removed and the cache is filled starting from the first not-found item that was asked.
The method of retrieving this information is by overriding IndexedContainer's getIdByIndex() method in the ObjectContainer. I try/catch the call to super.getIdByIndex(), if it throws an IndexOutOfBoundsException, i fill the cache as described above and retry getting the element (which now should exist within the cache range).
This works fine, when used with the table and you browse the table with large jumps. But when the table is scrolled down bit-by-bit, it seems like the super.getIdByIndex() never throws an exception, but dies with another exception before it gets back thus far. I catch any and all exceptions ("catch (Exception e)"). I get only the following exception, which has no indications or references to the currently active code.
java.lang.ArrayIndexOutOfBoundsException: 56 at com.itmill.toolkit.ui.Table.paintContent(Table.java:1778) at com.itmill.toolkit.ui.AbstractComponent.paint(AbstractComponent.java:635) at com.itmill.toolkit.terminal.gwt.server.CommunicationManager.handleUidlRequest(CommunicationManager.java:392) at com.itmill.toolkit.terminal.gwt.server.ApplicationServlet.service(ApplicationServlet.java:431) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) 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:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) 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:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:613)
The number 56 seems a bit arbitrary, as the cache size is currently set to 200, and the smallest requested index should be no less than 150.
So, the question is: Am I doing something wrong, or have I found a bug in the gwt-side implementation of the Table?
Actually, there was a bug in the client-side Table that made it fetch more and more rows in some cases. It was fixed just two days before your post, so you might not have that fix yet - if that is the case, could you please try updating, and let us know if it makes a difference?
Link to the changeset:
Updating to 5.2.4 seemed to do the trick. Sorry for the false alarm.