[
https://issues.apache.org/jira/browse/OAK-3584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290656#comment-15290656
]
Tomek Rękawek commented on OAK-3584:
------------------------------------
Backported to 1.2 in [r1744526|https://svn.apache.org/r1744526].
> PathNotFoundException when reading child node and property definitions below
> nt root
> ------------------------------------------------------------------------------------
>
> Key: OAK-3584
> URL: https://issues.apache.org/jira/browse/OAK-3584
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
> Reporter: angela
> Fix For: 1.4, 1.3.10, 1.2.16
>
>
> while randomly reading nodes from the repository i run into unexpected
> {{PathNotFoundException}} for existing nodes. Taking a closer look I found
> that all of these odd failures are caused by the first child node or property
> definition node of a registered node type represented in the content. For
> example:
> - /jcr:system/jcr:nodeTypes/nt:version/jcr:childNodeDefinition[1]
> - /jcr:system/jcr:nodeTypes/nt:version/jcr:propertyDefinition[1]
> the following paths however are properly resolved:
> - /jcr:system/jcr:nodeTypes/nt:version/jcr:propertyDefinition[2]
> - /jcr:system/jcr:nodeTypes/nt:version/jcr:propertyDefinition[3]
> since the indices in JCR are 1-base
> {{/jcr:system/jcr:nodeTypes/nt:version/jcr:childNodeDefinition[1]}} is
> equivalent to
> {{/jcr:system/jcr:nodeTypes/nt:version/jcr:childNodeDefinition}} and the
> name-listener within {{NamePathMapperImpl}}, will consequently cut the index
> when resolving the JCR path to an Oak path.
> So, IMHO the fundamental problem is actually not located in the
> name-resolution but rather in the fact that the node type code base add the
> {{[1]}}, when persisting child definitions into the repository. that should
> be fixable for new installations... for existing installations we might
> consider working around the bug in oak-jcr.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
