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

Reply via email to