[
https://issues.apache.org/jira/browse/JCR-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14035519#comment-14035519
]
Alex Parvulescu commented on JCR-3779:
--------------------------------------
[~dpfister] I adjusted the release version as this did not make it into the 2.8
release. If you want to include it into a 2.8.x please backport it to the 2.8
branch.
> 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.9
>
>
> 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)
