You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Martijn Hendriks <ma...@gx.nl> on 2007/04/06 09:47:34 UTC

Cannot remove node due to ItemNotFoundException

Hi all,

I am trying to remove a node with the following piece of code (using
Jackrabbit 1.2.1 + some patches):

// remove the item at absPath
Item item = jcrSession.getItem(absPath);
String targetPath = item.getParent().getPath();
item.remove();

This always fails with the following exception:

javax.jcr.ItemNotFoundException:
23685cab-326d-444e-ad38-c3064541dc3c/{http://gx.nl/wm9object}password
        at
org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.ja
va:527)
        at
org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:325)
        at
org.apache.jackrabbit.core.NodeImpl.onRemove(NodeImpl.java:687)
        at
org.apache.jackrabbit.core.NodeImpl.onRemove(NodeImpl.java:672)
        at
org.apache.jackrabbit.core.NodeImpl.onRemove(NodeImpl.java:672)
        at
org.apache.jackrabbit.core.NodeImpl.onRemove(NodeImpl.java:672)
        at
org.apache.jackrabbit.core.NodeImpl.removeChildNode(NodeImpl.java:636)
        at
org.apache.jackrabbit.core.ItemImpl.internalRemove(ItemImpl.java:871)
        at
org.apache.jackrabbit.core.ItemImpl.remove(ItemImpl.java:1055)

The property that is to be removed in NodeImpl.onRemove() line 687 is a
non-mandatory property which is not set for the node.  So the call to
itemMgr.getItem(..) throws an ItemNotFoundException, which, I expect, is
correct behavior.
I think that it is strange that this particular property is part of the
state, while other non-mandatory properties that are also not set, are
not part of the state. I guess that the property which causes the error
should therefore not be part of the state. The question now is: how
could the node's state end up in this bad state?

(I noticed JCR-768 and applied the small change from the svn commit, but
the exception is still thrown).

Regards,

Martijn Hendriks
<GX> creative online development B.V.
 
t: 024 - 3888 261
f: 024 - 3888 621
e: martijnh@gx.nl
 
Wijchenseweg 111
6538 SW Nijmegen
http://www.gx.nl/ 

RE: Cannot remove node due to ItemNotFoundException

Posted by Martijn Hendriks <ma...@gx.nl>.
Hi Stefan,

Last week this exception occurred every time I tried, but now, after a
restart of our application, it all works like a charm. I guess that the
NodeState got into a bad state due to some kind of race condition that
did not occur during/after the restart. To answer your questions: the
issue was reproducible with only one item. We don't use a custom access
manager and I didn't check out the svn head or any other revision. I've
looked into it, but I could not reproduce it, unfortunately. If it
happens again I will investigate it further..

Best wishes,

Martijn

> -----Original Message-----
> From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com] 
> Sent: Friday, April 06, 2007 1:04 PM
> To: dev@jackrabbit.apache.org
> Subject: Re: Cannot remove node due to ItemNotFoundException
> 
> hi martijn,
> 
> On 4/6/07, Martijn Hendriks <ma...@gx.nl> wrote:
> > Hi all,
> >
> > I am trying to remove a node with the following piece of 
> code (using 
> > Jackrabbit 1.2.1 + some patches):
> >
> > // remove the item at absPath
> > Item item = jcrSession.getItem(absPath); String targetPath = 
> > item.getParent().getPath(); item.remove();
> >
> > This always fails with the following exception:
> >
> > javax.jcr.ItemNotFoundException:
> 
> hmm, a couple of questions:
> 
> - is the issue reproduceable with any item or does it
>   only occur on an item with a specific definition?
> - is a custom access manager involved? if yes, try
>   again after disabling it in order to isolate the issue.
> - is the issue reproduceable using either svn head
>   revision or a released jackrabbit version? if so,
>   please post a jira issue and, if possible, attach a
>   simple test case.
> 
> happy eastern!
> stefan
> 
> 
> > 
> 23685cab-326d-444e-ad38-c3064541dc3c/{http://gx.nl/wm9object}password
> >         at
> > 
> org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.
> > ja
> > va:527)
> >         at
> > org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:325)
> >         at
> > org.apache.jackrabbit.core.NodeImpl.onRemove(NodeImpl.java:687)
> >         at
> > org.apache.jackrabbit.core.NodeImpl.onRemove(NodeImpl.java:672)
> >         at
> > org.apache.jackrabbit.core.NodeImpl.onRemove(NodeImpl.java:672)
> >         at
> > org.apache.jackrabbit.core.NodeImpl.onRemove(NodeImpl.java:672)
> >         at
> > 
> org.apache.jackrabbit.core.NodeImpl.removeChildNode(NodeImpl.java:636)
> >         at
> > 
> org.apache.jackrabbit.core.ItemImpl.internalRemove(ItemImpl.java:871)
> >         at
> > org.apache.jackrabbit.core.ItemImpl.remove(ItemImpl.java:1055)
> >
> > The property that is to be removed in NodeImpl.onRemove() 
> line 687 is 
> > a non-mandatory property which is not set for the node.  So 
> the call 
> > to
> > itemMgr.getItem(..) throws an ItemNotFoundException, which, 
> I expect, 
> > is correct behavior.
> > I think that it is strange that this particular property is part of 
> > the state, while other non-mandatory properties that are 
> also not set, 
> > are not part of the state. I guess that the property which 
> causes the 
> > error should therefore not be part of the state. The 
> question now is: 
> > how could the node's state end up in this bad state?
> >
> > (I noticed JCR-768 and applied the small change from the 
> svn commit, 
> > but the exception is still thrown).
> >
> > Regards,
> >
> > Martijn Hendriks
> > <GX> creative online development B.V.
> >
> > t: 024 - 3888 261
> > f: 024 - 3888 621
> > e: martijnh@gx.nl
> >
> > Wijchenseweg 111
> > 6538 SW Nijmegen
> > http://www.gx.nl/
> >
> 

Re: Cannot remove node due to ItemNotFoundException

Posted by Stefan Guggisberg <st...@gmail.com>.
hi martijn,

On 4/6/07, Martijn Hendriks <ma...@gx.nl> wrote:
> Hi all,
>
> I am trying to remove a node with the following piece of code (using
> Jackrabbit 1.2.1 + some patches):
>
> // remove the item at absPath
> Item item = jcrSession.getItem(absPath);
> String targetPath = item.getParent().getPath();
> item.remove();
>
> This always fails with the following exception:
>
> javax.jcr.ItemNotFoundException:

hmm, a couple of questions:

- is the issue reproduceable with any item or does it
  only occur on an item with a specific definition?
- is a custom access manager involved? if yes, try
  again after disabling it in order to isolate the issue.
- is the issue reproduceable using either svn head
  revision or a released jackrabbit version? if so,
  please post a jira issue and, if possible, attach a
  simple test case.

happy eastern!
stefan


> 23685cab-326d-444e-ad38-c3064541dc3c/{http://gx.nl/wm9object}password
>         at
> org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.ja
> va:527)
>         at
> org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:325)
>         at
> org.apache.jackrabbit.core.NodeImpl.onRemove(NodeImpl.java:687)
>         at
> org.apache.jackrabbit.core.NodeImpl.onRemove(NodeImpl.java:672)
>         at
> org.apache.jackrabbit.core.NodeImpl.onRemove(NodeImpl.java:672)
>         at
> org.apache.jackrabbit.core.NodeImpl.onRemove(NodeImpl.java:672)
>         at
> org.apache.jackrabbit.core.NodeImpl.removeChildNode(NodeImpl.java:636)
>         at
> org.apache.jackrabbit.core.ItemImpl.internalRemove(ItemImpl.java:871)
>         at
> org.apache.jackrabbit.core.ItemImpl.remove(ItemImpl.java:1055)
>
> The property that is to be removed in NodeImpl.onRemove() line 687 is a
> non-mandatory property which is not set for the node.  So the call to
> itemMgr.getItem(..) throws an ItemNotFoundException, which, I expect, is
> correct behavior.
> I think that it is strange that this particular property is part of the
> state, while other non-mandatory properties that are also not set, are
> not part of the state. I guess that the property which causes the error
> should therefore not be part of the state. The question now is: how
> could the node's state end up in this bad state?
>
> (I noticed JCR-768 and applied the small change from the svn commit, but
> the exception is still thrown).
>
> Regards,
>
> Martijn Hendriks
> <GX> creative online development B.V.
>
> t: 024 - 3888 261
> f: 024 - 3888 621
> e: martijnh@gx.nl
>
> Wijchenseweg 111
> 6538 SW Nijmegen
> http://www.gx.nl/
>