Major Description
This is a hardly reproducible bug, and even more hard to fix it:
Every time DataRow is created, a new UUID is associated to it. DataRow is created by DataTableModel lazily. DataTableModel can be recreated by its memento, and of cource it is sometimes recreated during deserialization.
DataRowWkt is a representation of DataRow connected by DataTableModel (or its memento), and UUID. But recreation of DataTableModel creates new UUID for rows, so DataRowWkt, after deserialization, can't find the DataRow object by the original UUID. Clicking to the checkbox on the row of the wicket table this causes an NPE (datarow still null, DataRowToggleWkt.getBindable(DataRow) can not call getSelectToggle()).
The origin of the bug is the invalid DataRow representation (the uuid), which is recreated (a new one associated) every time, when DataTableModel serialized and deserialized.
My suggestion is to use the getBookmark of ManagedObject maybe in form of a String, and use this String to identify the DataRow instead of UUID.
This is more consistent method to identify the datarow. (If String is too brute force solution, it could be any of OidDto or UUID depending on the ManagedObject supports Bookmark)
So DataTableModel.lookupDataRow, and DataRowWkt should be changed as well.
Other solution, to save the UUIDs into the DataTableModel Memento, using the index somehow as the association base, and use them in the recreation.
It would be a good idea to protect DataRowToggleWkt from the null datarow value as well, or at least from the NPE caused by the unsuccessful row lookup.