[ 
https://issues.apache.org/jira/browse/JCR-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frank Karlstrøm updated JCR-768:
--------------------------------

    Description: 
When calling Node.getPath() anytime, no mather if its before or after save, and 
when deleting nodes, the internal reference points to the wrong nodes. 
The attached test will always fail with a reference exception. We have seen 
other configurations where a node suddenly behaves as the root node, and yet 
other configurations where the node we though we deleted still exists, and 
another noe has now disappeared.

I do not know what causes the bug,a good bet is perhaps the 
CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was 
introduced in 1.1.

Have also tested the latest release: 1.2.2, and the bug is still present there.


  was:
When calling Node.getPath() anytime, no mather if its before or after save, and 
when deleting nodes, the internal reference points to the wrong nodes. The 
attached test will fail with a reference exception. We have seen other 
configurations where a node suddenly behaves as the root node, and yet other 
configurations where the node we though we deleted still exists, and another 
noe has now disappeared.

I do not know what causes the bug,a good bet is perhaps the 
CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was 
introduced in 1.1.

Have also tested the latest release: 1.2.2, and the bug is still present there.



> Node.getPath() will make the corrupt the session
> ------------------------------------------------
>
>                 Key: JCR-768
>                 URL: https://issues.apache.org/jira/browse/JCR-768
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1, 1.1.1, 1.2.1, 1.2.2
>         Environment: JDK 1.5, WinXP
>            Reporter: Frank Karlstrøm
>            Priority: Critical
>
> When calling Node.getPath() anytime, no mather if its before or after save, 
> and when deleting nodes, the internal reference points to the wrong nodes. 
> The attached test will always fail with a reference exception. We have seen 
> other configurations where a node suddenly behaves as the root node, and yet 
> other configurations where the node we though we deleted still exists, and 
> another noe has now disappeared.
> I do not know what causes the bug,a good bet is perhaps the 
> CachingHierarchyManager?. It was not present in Jackrabbit 1.0.1, but was 
> introduced in 1.1.
> Have also tested the latest release: 1.2.2, and the bug is still present 
> there.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to