I think I have it nailed now.  It looks like our SimpleAccessManager
implementation methods are being called on an ocm.save.  I get the issue
below when someone calls an ocm#delete and then an ocm#save.  Lesson
learned, the SimpleAccessManager can't always depend on a path still
actually existing.

Sorry to waste your time.

Ryan

On Tue, Apr 21, 2009 at 1:04 PM, Ryan Kruse <[email protected]> wrote:

> Thanks for the quick reply Alex.  Here are the relevant paths in my
> repository.
>
> /h9:analytics
> /h9:analytics/h9:notes
> /h9:analytics/h9:notes/d51ea95d-4d31-49a9-a0c8-b2d2bec4ca58
>
> The last one is a name generated from an internal guid, it is not the
> primary object UUID.
>
> I have tried the getItem and itemExists with the full path as noted in my
> first email, but neither return anything.  Using my JCR Browser eclipse
> plugin I can put that path in the find and it locates it.
>
>
> On Tue, Apr 21, 2009 at 11:07 AM, Alexander Klimetschek 
> <[email protected]>wrote:
>
>> On Tue, Apr 21, 2009 at 5:43 PM, Ryan Kruse <[email protected]> wrote:
>> > I am puzzled by some behavior in the SessionImpl class.  See attached
>> for a
>> > screenshot of my repo structure.
>>
>> Apache mailing lists don't support attachments.
>>
>> >
>> > This works...
>> > session.getItem("/h9:analytics/h9:notes");
>> >
>> > But this throws PathNotFoundException.  Any ideas why?  I can plug that
>> same
>> > path in my JCR Browser plugin and it finds the node.
>> >
>> session.getItem("/h9:analytics/h9:notes/d51ea95d-4d31-49a9-a0c8-b2d2bec4ca58");
>>
>> Both examples are getItem() calls. From your mail's subject I would
>> guess you mean one is session.itemExists and one is session.getItem.
>> Could you clarify?
>>
>> Anyway, both methods only handle paths based on node names and not on
>> UUIDs (the second example looks like the last part is a UUID). For
>> UUID-based resolving, use session.getNodeByUUID().
>>
>> Regards,
>> Alex
>>
>> --
>> Alexander Klimetschek
>> [email protected]
>>
>
>

Reply via email to