You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Alex Parvulescu (JIRA)" <ji...@apache.org> on 2014/06/18 11:43:09 UTC

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

    [ 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)