GeneratedPropertyItem.getItemProperty throws java.langNullPointerException

Vaadin 6 / 7 / 8
1

Hello all,
I am getting a suspicious exception while updating data in a Grid within an application I am developing. I am going to shortly describe the problem, but I want to point out that the application does work perfectly with Vaadin 7.5.10 and I proved it working also with 7.6.0-alpha2, but if I recompile it with Vaadin 7.6.0-beta1 on, the problem appears. Here is the use case for the occurrence of the error:

  • Data from a row of the Grid is modified and saved (the Grid editor properly saves the change and after the commit the modified data are correctly displayed)
  • The modified data are sent to the backend and properly saved into the database (checked against the database frontend)
  • The data are properly reloaded into the Grid, but soon after the error appears recursively and endlessly. Here follows the stacktrace:

java.lang.NullPointerException: null
at com.vaadin.data.util.GeneratedPropertyContainer$GeneratedPropertyItem.getItemProperty(GeneratedPropertyContainer.java:144) ~[vaadin-server-7.6.0.rc1.jar:7.6.0.rc1]

at com.vaadin.ui.Grid$RowDataGenerator.writeData(Grid.java:2192) ~[vaadin-server-7.6.0.rc1.jar:7.6.0.rc1]

at com.vaadin.ui.Grid$RowDataGenerator.generateData(Grid.java:2152) ~[vaadin-server-7.6.0.rc1.jar:7.6.0.rc1]

at com.vaadin.server.communication.data.RpcDataProviderExtension.getRowData(RpcDataProviderExtension.java:395) ~[vaadin-server-7.6.0.rc1.jar:7.6.0.rc1]

at com.vaadin.server.communication.data.RpcDataProviderExtension.internalUpdateRows(RpcDataProviderExtension.java:521) ~[vaadin-server-7.6.0.rc1.jar:7.6.0.rc1]

at com.vaadin.server.communication.data.RpcDataProviderExtension.beforeClientResponse(RpcDataProviderExtension.java:347) ~[vaadin-server-7.6.0.rc1.jar:7.6.0.rc1]

at com.vaadin.server.communication.UidlWriter.write(UidlWriter.java:112) ~[vaadin-server-7.6.0.rc1.jar:7.6.0.rc1]

at com.vaadin.server.communication.AtmospherePushConnection.push(AtmospherePushConnection.java:168) [vaadin-server-7.6.0.rc1.jar:7.6.0.rc1]

at com.vaadin.server.communication.PushHandler$2.run(PushHandler.java:150) [vaadin-server-7.6.0.rc1.jar:7.6.0.rc1]

at com.vaadin.server.communication.PushHandler.callWithUi(PushHandler.java:243) [vaadin-server-7.6.0.rc1.jar:7.6.0.rc1]

at com.vaadin.server.communication.PushHandler.onMessage(PushHandler.java:503) [vaadin-server-7.6.0.rc1.jar:7.6.0.rc1]

at com.vaadin.server.communication.PushAtmosphereHandler.onMessage(PushAtmosphereHandler.java:88) [vaadin-server-7.6.0.rc1.jar:7.6.0.rc1]

at com.vaadin.server.communication.PushAtmosphereHandler.onRequest(PushAtmosphereHandler.java:78) [vaadin-server-7.6.0.rc1.jar:7.6.0.rc1]

at org.atmosphere.cpr.AsynchronousProcessor.action(AsynchronousProcessor.java:199) [atmosphere-runtime-2.2.7.vaadin1.jar:2.2.7.vaadin1]

at org.atmosphere.cpr.AsynchronousProcessor.suspended(AsynchronousProcessor.java:107) [atmosphere-runtime-2.2.7.vaadin1.jar:2.2.7.vaadin1]

at org.atmosphere.container.Jetty9AsyncSupportWithWebSocket.service(Jetty9AsyncSupportWithWebSocket.java:180) [atmosphere-runtime-2.2.7.vaadin1.jar:2.2.7.vaadin1]

at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:2075) [atmosphere-runtime-2.2.7.vaadin1.jar:2.2.7.vaadin1]

at org.atmosphere.websocket.DefaultWebSocketProcessor.dispatch(DefaultWebSocketProcessor.java:571) [atmosphere-runtime-2.2.7.vaadin1.jar:2.2.7.vaadin1]

at org.atmosphere.websocket.DefaultWebSocketProcessor$3.run(DefaultWebSocketProcessor.java:333) [atmosphere-runtime-2.2.7.vaadin1.jar:2.2.7.vaadin1]

at org.atmosphere.util.VoidExecutorService.execute(VoidExecutorService.java:101) [atmosphere-runtime-2.2.7.vaadin1.jar:2.2.7.vaadin1]

at org.atmosphere.websocket.DefaultWebSocketProcessor.dispatch(DefaultWebSocketProcessor.java:328) [atmosphere-runtime-2.2.7.vaadin1.jar:2.2.7.vaadin1]

at org.atmosphere.websocket.DefaultWebSocketProcessor.invokeWebSocketProtocol(DefaultWebSocketProcessor.java:425) [atmosphere-runtime-2.2.7.vaadin1.jar:2.2.7.vaadin1]

at org.atmosphere.container.Jetty9WebSocketHandler.onWebSocketText(Jetty9WebSocketHandler.java:92) [atmosphere-runtime-2.2.7.vaadin1.jar:2.2.7.vaadin1]

at org.eclipse.jetty.websocket.common.events.JettyListenerEventDriver.onTextMessage(JettyListenerEventDriver.java:128) [websocket-common-9.2.5.v20141112.jar:9.2.5.v20141112]

at org.eclipse.jetty.websocket.common.message.SimpleTextMessage.messageComplete(SimpleTextMessage.java:69) [websocket-common-9.2.5.v20141112.jar:9.2.5.v20141112]

at org.eclipse.jetty.websocket.common.events.AbstractEventDriver.appendMessage(AbstractEventDriver.java:64) [websocket-common-9.2.5.v20141112.jar:9.2.5.v20141112]

at org.eclipse.jetty.websocket.common.events.JettyListenerEventDriver.onTextFrame(JettyListenerEventDriver.java:122) [websocket-common-9.2.5.v20141112.jar:9.2.5.v20141112]

at org.eclipse.jetty.websocket.common.events.AbstractEventDriver.incomingFrame(AbstractEventDriver.java:160) [websocket-common-9.2.5.v20141112.jar:9.2.5.v20141112]

at org.eclipse.jetty.websocket.common.WebSocketSession.incomingFrame(WebSocketSession.java:309) [websocket-common-9.2.5.v20141112.jar:9.2.5.v20141112]

at org.eclipse.jetty.websocket.common.extensions.ExtensionStack.incomingFrame(ExtensionStack.java:214) [websocket-common-9.2.5.v20141112.jar:9.2.5.v20141112]

at org.eclipse.jetty.websocket.common.Parser.notifyFrame(Parser.java:220) [websocket-common-9.2.5.v20141112.jar:9.2.5.v20141112]

at org.eclipse.jetty.websocket.common.Parser.parse(Parser.java:258) [websocket-common-9.2.5.v20141112.jar:9.2.5.v20141112]

at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.readParse(AbstractWebSocketConnection.java:613) [websocket-common-9.2.5.v20141112.jar:9.2.5.v20141112]

at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable(AbstractWebSocketConnection.java:468) [websocket-common-9.2.5.v20141112.jar:9.2.5.v20141112]

at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) [jetty-io-9.2.5.v20141112.jar:9.2.5.v20141112]

at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:620) [jetty-util-9.2.5.v20141112.jar:9.2.5.v20141112]

at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:540) [jetty-util-9.2.5.v20141112.jar:9.2.5.v20141112]

at java.lang.Thread.run(Thread.java:745) [na:1.8.0_31]

I cannot figure out what the issue is all about. Of course if I avoid using the GeneratedPropertyContainer the error does not appear, but first of all this is not what I want and I guess the problem is not on the GeneratedPropertyContainer itself, but rather with something I might be doing wrong.
Is there someone having any idea on where the root cause might be?

Thanks in advance for any help!

2

Looks like somebody is adding or asking for a null itemId.

    at com.vaadin.data.util.GeneratedPropertyContainer$GeneratedPropertyItem.getItemProperty(GeneratedPropertyContainer.java:144) ~[vaadin-server-7.6.0.rc1.jar:7.6.0.rc1]

The code in GeneratedPropertyContainer.java:144 is

return wrappedItem.getItemProperty(id); so likely wrappedItem == null, which it can only be if

protected GeneratedPropertyItem(Object itemId, Item item) { is called with item=null. So set a breakpoint in that constructor and see who is calling it with item==null

3

Thanks a lot!
By debugging following your suggestion I found out that there was a null item indeed.
As I have no good knowledge yet on the Grid databinding, I guess the problem is due to the fact that I perform a removal of the data from within the container (dataContainer.removeAllItems(), with dataContainer being a BeanItemContainer) before reassigning new ones retrieved from the database to it (dataContainer.addAll(…)).
By commenting out the call to removeAllItems() the error is indeed not showing.
To my surprise I also realized that I might not need to perform the removal of the data before, as addAll(…) does not re-insert the existing ones (can you confirm this?)
What it remains still strange to me is that everything was working absolutely Ok with Vaadin versions <= 7.6.0-alpha2 and appeares some time later (I can’t actually state from which exact version, as after 7.6.0-alpha2, my next attempt it has been with 7.6.0-beta1).
Regards!

4

There were some possibly related fixes in 7.6.0.rc1 if I remember correctly, so it makes sense to test that before debugging further

5

7.6.0.rc1 is actually the version I am currently using and the issue is also appearing. So, taking into account that I recompiled the application with 7.5.10, 7.6.0.alpha2, 7.6.0.beta1, 7.6.0.beta2 and 7.6.0.rc1 and that the issue is not showing with versions <= 7.6.0.alpha2, but it is showing with all versions >= 7.6.0.beta1, I guess some modification was done between alpha2 and beta1 that makes the issue appear.

6

Regarding removing and adding, the itemId for each item in a container must be unique and Container.addItem is specified as “The new Item is returned, and it is ready to have its Properties modified. Returns null if the operation fails or the Container already contains a Item with the given ID.”. This is also how addBean/addAll in BeanItemContainer works, and the item id is the bean itself so adding it multiple times will not cause it to end up many times in the container.

What you are experiencing though sounds a bit like https://dev.vaadin.com/ticket/18685 (GeneratedPropertyContainer might throw NPE on item add)

7

Ok, in my case I use a BeanItemContainer as a source container for my Grid which item identifier, as you say and I understood from https://vaadin.com/book/-/page/datamodel.container.html#datamodel.container.beanitemcontainer is the bean itself, unless the bean implements the hashCode() and equals() methods.
Now I am in this latter case as I implemented both hashCode() and equals() methods in my bean, which are calculated, for convenience, out of a unique field and a revision number field.
The container is then wrapped into a GeneratedPropertyContainer for convenience.
Now, when I do update an entry in the Grid, the related bean is modified and eventually the related entity is persisted into the database, therefore when I retrieve the entities back from the database and I perform the addAll() (without doing the remove), if I understood properly, I should expect my Grid to show two entries with the same unique field and different revision number.
If positive then there is something weird, because I only see the updated and not the original item (which is incidentally exactly what I want)… unless of course I am misunderstanding something.
Concerning ticket #18685, I see that it has been opened already in version 7.5.4, therefore if my issue is part of it, I mind why I wasn’t experiencing the same issue with the older versions of Vaadin I mentioned.

8

Sorry about my last statement; it was actually inaccurate. In fact if I re-order the items in the Grid I see both the original and modified entries.

9

I think the problem is caused by a bug in the slection model and how asyncrounous push notifications are processed. The error happens when a push notification results in an attemp to retreive items from the container data source that have just been removed.

I have found a workaround. Try adding the following line after updaing the contents of the container data source. Replace the slection mode with the mode your using.

yourGrid.setSelectionMode(SelectionMode.SINGLE); This will replace your exisisting slection model with a new one. This seems to be a workaround for the probem.

10

Hello,
I am currently undergoing an overall refactoring of the frontend code but as soon as it is ready again, I will try the workaround you suggest!

Thanks for the time being!