You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Marcel Reutegger (JIRA)" <ji...@apache.org> on 2016/03/03 12:43:18 UTC
[jira] [Commented] (OAK-4085) Malformed node type definition when
reregistered after upgrade
[ https://issues.apache.org/jira/browse/OAK-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177710#comment-15177710 ]
Marcel Reutegger commented on OAK-4085:
---------------------------------------
The problem is with how {{NodeTypeTemplateImpl.writeItemDefinitions()}} overwrites existing definition child nodes.
{noformat}
for (ItemDefinitionTemplate template : itemDefTemplates) {
String name = nodeName(nodeName, index);
tree = nodeTypeTree.getChild(name);
if (!tree.exists()) {
tree = nodeTypeTree.addChild(name);
tree.setProperty(
JCR_PRIMARYTYPE, primaryTypeName, NAME);
}
template.writeTo(tree);
index++;
}
{noformat}
The sequence of child node names will be 'jcr:childNodeDefinition', 'jcr:childNodeDefinition[2]', 'jcr:childNodeDefinition[3]', etc. This is correct from a JCR point of view, but will skip a 'jcr:childNodeDefinition[1]' child node from a previous Oak version.
> Malformed node type definition when reregistered after upgrade
> ---------------------------------------------------------------
>
> Key: OAK-4085
> URL: https://issues.apache.org/jira/browse/OAK-4085
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, jcr
> Affects Versions: 1.3.10
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Priority: Blocker
> Fix For: 1.4.1
>
>
> When a node type is reregistered after an upgrade from an earlier release, the resulting node type definition may be malformed. As noted in OAK-3584, the node type representation in content was not compliant with JCR already before. As explained here the situation after an upgrade is even worse: http://markmail.org/message/7kjkqlt3erbocpin
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)