[ https://issues.apache.org/jira/browse/JCR-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dominique Pfister resolved JCR-3779. ------------------------------------ Resolution: Fixed Fix Version/s: 2.8 Fixed in revision 1596550. > Node.getPath() returns inconsistent values depending on whether node is saved > or not > ------------------------------------------------------------------------------------ > > Key: JCR-3779 > URL: https://issues.apache.org/jira/browse/JCR-3779 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core > Affects Versions: 2.6.4 > Reporter: Jan Haderka > Fix For: 2.8 > > > Consider following code: > {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” > {code} > 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. > {code} > 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()); > {code} > 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. -- This message was sent by Atlassian JIRA (v6.2#6252)