You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Christian Stocker <ch...@liip.ch> on 2012/03/03 09:03:04 UTC
JSOP/davex removing same-name siblings question
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
Re: JSOP/davex removing same-name siblings question
Posted by Christian Stocker <ch...@liip.ch>.
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
Re: JSOP/davex removing same-name siblings question
Posted by Angela Schreiber <an...@adobe.com>.
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
>
>
>