Details
-
Task
-
Resolution: Fixed
-
Neutral
-
6.0
-
None
-
None
-
-
Empty show more show less
-
Empty show more show less
-
Foundation 4, Foundation 5
-
8
Description
While implementing the initial version of the TreeView (and to some extend - the ListView), we encountered some problems with using Jackrabbit in Vaadin Grids.
In particular - Grid tends to cache items (i.e. Nodes!) within the guts of its DataCommunicator (glue between the client and server-side, manages DataProvider), which occasionally would result into repo exceptions caused by attempts to interact with stale/gone JCR nodes. This might happen e.g. if a Node has been moved around/deleted by another user or by another app. Even Grid's own operations (like inline editing) could cause issues.
The current implementation tries to reduce the possibility of such problems, but further assessment/testing needs to be done.
What exactly could be done:
- inspect the current state of JCR support (node wrappers, Grid extensions, availability checks etc).
- thorough manual testing of different concurrent scenarios of JCR workspace modifications and Grid's reaction on them.
- Repo test case for the JcrHierarchicalDataProvider, possibly with some involvment of Grid as well.
- come up with potential future integration testing options for this functionality.
Checklists
Attachments
Issue Links
- is causing
-
MGNLUI-5060 New framework: move filtering logic from wrapper back to data provider
-
- Closed
-
- is depended upon by
-
ECOMMERCE-171 IllegalStateException thrown after changing password in PasswordManager
-
- Closed
-
- supersedes
-
MGNLUI-4587 Make sure Grid/TreeGrid are resilient and eventually consisten with un-observed JCR workspace changes
-
- Closed
-
-
MGNLUI-4589 Prevent RepoExceptions when selecting removed Node/Property in Grid/TreeGrid
-
- Closed
-
-
MGNLUI-4578 Make JCR-bound Tree/List views resilient to the underlying workspace changes
-
- Closed
-
- mentioned in
-
Page Loading...