hi javier yep, that's a bug. i created a jira issue: http://issues.apache.org/jira/browse/JCR-261
it's an issue with the CachingHierarchyManager which doesn't update/flush its path cache correctly on removal of same-name sibling entries. please note that there was never the risk of unintenionally removing the root node, the msg of the exception is misleading. btw: if you comment all "dump(topNode);" stmts in your test case the problem doesn't occur anymore ;) thanks for finding and reporting this bug! cheers stefan On 10/25/05, Javier Bermejo <[EMAIL PROTECTED]> wrote: > Hi, > > I'm trying to make a content management system using JSR170 and the > Jackrabbit implementation using ORM-persistence connecting to a PostgreSQL. > > I think I have discovered a bug in jackrabbit when trying to delete > several nodes using SameNameSibling. > > I have developed a test you can place in: > > src/test/org/apache/jackrabbit/test/api/ > > and add the testCase to the suite in: > > src/test/org/apache/jackrabbit/test/api/TestAll.java > > suite.addTestSuite(RemoveSameNameSiblingNodesTest.class); > > The structure of the test is the following one: > 1º I add a first topNode under the rootNode. > 2º I add 4 nodes with the same path (with no properties to avoid > complexity of the test) > 3º Later, I get a NodeIterator to get the 4 previous added nodes: > > NodeIterator it = topNode.getNodes(myNodePath); > 4º Now, this is the suspect BUG, inside the while loop getting the > nodes, I make a call to the remove() item method. If I save each change > on the parent node, you can see that every remove operation have a > strange behaviour and when you are removing the third item it tries to > delete the root node!!!! (You can see the dump output of the test) > > You can avoid this bug saving the session or the rootnode outside the > while loop. > > Best regards, > Javier > > >
