[
https://issues.apache.org/jira/browse/OAK-5229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15828014#comment-15828014
]
Alex Parvulescu commented on OAK-5229:
--------------------------------------
first look at this issue, I found the problem to be in this area of the code
[0].
it seems to reference OAK-713 and the current behavior seems to be that after
exhausting the current node type hierarchy (in the current test {{nt:file}}),
it will fall back to checking residual definitions (basically {{nt:base}})
which will accept anything, so the repo becomes inconsistent. If I'm reading
the issue correctly, this change was about something else, and the current
behavior being a bit of a side effect.
Not sure yet what the impact is if we re-enable the strictness in the type
checks.
[0]
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/nodetype/EffectiveType.java#L142
> Using Node.setPrimaryType() should fail if non-matching childnodes
> ------------------------------------------------------------------
>
> Key: OAK-5229
> URL: https://issues.apache.org/jira/browse/OAK-5229
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Affects Versions: 1.5.14
> Reporter: Tobias Bocanegra
> Assignee: Alex Parvulescu
> Priority: Critical
> Fix For: 1.5.18
>
>
> 1. Assume the following:
> {noformat}
> /testNode [nt:unstructured]
> /unstructured_child [nt:unstructured]
> {noformat}
> 2. setting "/testNode".setPrimaryType("nt:folder")
> 3. save the session.
> Altering the primary type works, thus leaving the repository in an
> inconsistent state.
> Interestingly, subsequent calls to
> "/testNiode/unstructured_child".setProperty() will fail:
> {noformat}
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0001:
> /test_node[[nt:folder]]: No matching definition found for child node
> unstructured_child with effective type [nt:unstructured]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
