Hi Angela Thanks a lot for the answer. I will make a jira issue about it. It's not a critical thing for us right now, we can circumvent it (and we don't work with same-name-siblings anyway, the problem is just when we want to delete accidental same name siblings to have a clean repo)
Greetings chregu On 07.03.12 12:30, Angela Schreiber wrote: > hi chregu > > the problem is multifolded having one part in jackrabbit-core > and a second one in the way sms are reflected over the SPI. > as a general summary i would say that having volatile index > both in jcr2spi and jackrabbit-core is pretty troublesome. > > without having a close look at it, i would suspect that > there is a bug in the sns-handling on the server-side (and > maybe also on the client though i remember that i added some > fixes some time in the past). > > feel free to create a jira issue (with test case ;) > > thanks > angela > > > On 3/3/12 9:03 AM, Christian Stocker wrote: >> Hi all >> >> I try to implement the JSOP "protocol" within Jackalope. Works fine (and >> saves me a lot of HTTP Requests compared to the old MKCOL/PUT/DELETE >> way). I have only one problem with removing same name siblings. >> >> If I have 2 same name siblings, doing the following >> >> *** >> - foo >> - foo >> *** >> >> ends up in >> >> <D:error xmlns:D="DAV:"> >> <dcr:exception xmlns:dcr="http://www.day.com/jcr/webdav/1.0";> >> <dcr:class>javax.jcr.PathNotFoundException</dcr:class> >> <dcr:message>/foo</dcr:message> >> </dcr:exception> >> </D:error> >> >> doing >> >> *** >> - foo >> - foo[2] >> *** >> >> I get >> >> <D:error xmlns:D="DAV:"> >> <dcr:exception xmlns:dcr="http://www.day.com/jcr/webdav/1.0";> >> <dcr:class>javax.jcr.PathNotFoundException</dcr:class> >> <dcr:message>/foo[2]</dcr:message> >> </dcr:exception> >> </D:error> >> >> >> What would work is >> >> *** >> - foo[2] >> - foo >> *** >> >> But then I have to use a certain order, seems to be not an ideal >> solution. >> >> Using a java client (configured for remoting via davex) and doing >> >> *** >> NodeIterator fs = root.getNodes("foo"); >> Node d = null; >> while (fs.hasNext()) { >> Node e = fs.nextNode(); >> if (d != null) { >> d.remove(); >> } >> d = e; >> } >> if (d != null) { >> d.remove(); >> } >> s.save(); >> *** >> >> does the first thing mentioned above (- /foo -/foo) and ends up with >> this stack trace >> >> *** >> javax.jcr.InvalidItemStateException: /foo >> at >> org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:72) >> >> at >> org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:51) >> >> at >> org.apache.jackrabbit.spi2davex.RepositoryServiceImpl$BatchImpl.start(RepositoryServiceImpl.java:611) >> >> at >> org.apache.jackrabbit.spi2davex.RepositoryServiceImpl$BatchImpl.access$600(RepositoryServiceImpl.java:547) >> >> at >> org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.submit(RepositoryServiceImpl.java:452) >> >> at >> org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.execute(WorkspaceManager.java:858) >> >> at >> org.apache.jackrabbit.jcr2spi.WorkspaceManager$OperationVisitorImpl.access$500(WorkspaceManager.java:817) >> >> at >> org.apache.jackrabbit.jcr2spi.WorkspaceManager.execute(WorkspaceManager.java:620) >> >> at >> org.apache.jackrabbit.jcr2spi.state.SessionItemStateManager.save(SessionItemStateManager.java:139) >> >> at >> org.apache.jackrabbit.jcr2spi.ItemImpl.save(ItemImpl.java:250) >> at >> org.apache.jackrabbit.jcr2spi.SessionImpl.save(SessionImpl.java:333) >> at Client.main(Client.java:51) >> *** >> >> Anyone knows if this is a bug? Or if I'm doing something wrong? >> >> chregu >> >> >> -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x0748D5FE
