[OAK-3584] PathNotFoundException when reading child node and property definitions below nt root

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.2.16, 1.3.10, 1.4
• Component/s: core, jcr
• Assignee: Unassigned
• Reporter: Angela Schreiber
• Created: 04/Nov/15 11:01
• Updated: 19/May/16 08:01
• Resolved: 04/Nov/15 14:23

Description

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.

Issue Links

• is related to: OAK-4085 Malformed node type definition when reregistered after upgrade