[
https://issues.apache.org/jira/browse/JCR-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13414330#comment-13414330
]
Unico Hommes commented on JCR-3368:
-----------------------------------
It seems that the special handling of the root node has nothing to do with this
issue. The issue seems to be with with removing intermediate paths in general.
If you change the test case to the following it also fails:
final Session session = getHelper().getSuperuserSession();
session.getRootNode().addNode("foo").addNode("bar").addNode("qux");
session.save();
session.getNode("/foo/bar/qux");
session.getNode("/foo/bar").remove();
session.getNode("/foo").hasNode("bar/qux");
Somehow the mapping from /foo to /foo/bar/qux does not get flushed. If I remove
the check whether the id is in the idCache in nodeRemoved method the test
passes.
> CachingHierarchyManager: inconsistent state after transient changes on root
> node
> ---------------------------------------------------------------------------------
>
> Key: JCR-3368
> URL: https://issues.apache.org/jira/browse/JCR-3368
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.2.12, 2.4.2, 2.5
> Reporter: Unico Hommes
> Attachments: HasNodeAfterRemoveTest.java
>
>
> See attached test case.
> You will see the following exception:
> javax.jcr.RepositoryException: failed to retrieve state of intermediary node
> at
> org.apache.jackrabbit.core.CachingHierarchyManager.resolvePath(CachingHierarchyManager.java:156)
> at
> org.apache.jackrabbit.core.HierarchyManagerImpl.resolveNodePath(HierarchyManagerImpl.java:372)
> at org.apache.jackrabbit.core.NodeImpl.getNodeId(NodeImpl.java:276)
> at
> org.apache.jackrabbit.core.NodeImpl.resolveRelativeNodePath(NodeImpl.java:223)
> at org.apache.jackrabbit.core.NodeImpl.hasNode(NodeImpl.java:2250)
> at
> org.apache.jackrabbit.core.HasNodeAfterRemoveTest.testRemove(HasNodeAfterRemoveTest.java:14)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:456)
> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> at junit.framework.TestSuite.run(TestSuite.java:238)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
> Caused by: org.apache.jackrabbit.core.state.NoSuchItemStateException:
> c7ccbcd3-0524-4d4d-a109-eae84627f94e
> at
> org.apache.jackrabbit.core.state.SessionItemStateManager.getTransientItemState(SessionItemStateManager.java:304)
> at
> org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:153)
> at
> org.apache.jackrabbit.core.HierarchyManagerImpl.getItemState(HierarchyManagerImpl.java:152)
> at
> org.apache.jackrabbit.core.HierarchyManagerImpl.resolvePath(HierarchyManagerImpl.java:115)
> at
> org.apache.jackrabbit.core.CachingHierarchyManager.resolvePath(CachingHierarchyManager.java:152)
> ... 29 more
> I tried several things to fix this but didn't find a better solution than to
> just wrap the statement
> NodeId id = resolveRelativeNodePath(relPath);
> in a try catch RepositoryException and return false when that exception
> occurs.
> In particular I tried changing the implementation to
> Path path = resolveRelativePath(relPath).getNormalizedPath();
> return itemMgr.nodeExists(path);
> However, the repository doesn't even start up with that. Aparently the code
> relies on the null check for id as well.
> Anyone have a better solution?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
