[JCR-3779] Node.getPath() returns inconsistent values depending on whether node is saved or not

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.6.4
• Fix Version/s: 2.9
• Component/s: jackrabbit-core
• Assignee: Unassigned
• Reporter: Jan Haderka
• Created: 20/May/14 22:35
• Updated: 27/Aug/14 14:34
• Resolved: 21/May/14 12:21

Description

Consider following code:

session.getRootNode().addNode(“foo”);
session.save();
Node fooNode = session.getNode("/foo");
assertEquals("/foo", fooNode.getPath());
session.move("/foo", "/bar");
Node barNode = session.getNode("/bar");
assertEquals(“/bar”, barNode.getPath()); <== this line actually fails, because barNode.getPath() still returns “/foo”

From a repo point of view, move didn’t happen as it was not persisted yet. But the example above is working in single session and in that session move did happen, so “local” view should be consistent.

Now aside from the weirdness of the above code, there is also consistency problem, because if I remove the save() call and run code like shown below, it will actually pass, so getPath() after move will behave differently whether or not was BEFORE the move persisted in the repo.

session.getRootNode().addNode(“foo”);
Node fooNode = session.getNode("/foo");
assertEquals("/foo", fooNode.getPath());
session.move("/foo", "/bar");
Node barNode = session.getNode("/bar");
assertEquals(“/bar”, barNode.getPath());

As per comment from Stefan Guggisberg, this happens only at the root node level and is most likely caused by bug in CachingHierarchyManager and related to JCR-3239 and JCR-3368.

Issue Links

• is related to: JCR-3239 Removal of a top level node doesn't update the hierarchy manager's cache.
• is related to: JCR-3368 CachingHierarchyManager: inconsistent state after transient changes on root node