Jan Haderka created JCR-3779:
--------------------------------
Summary: 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
Consider following code:
{format}
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”
{format}
>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.
{format}
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());
{format}
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)
