[
https://issues.apache.org/jira/browse/OAK-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14164972#comment-14164972
]
Michael Dürig commented on OAK-2121:
------------------------------------
It seems that somehow my comment re. this got lost. I committed a slightly edit
version of the test case.
I don't think this is a problem as there is nothing (much) wrong with setting
jcr:uuid on a non referenceable node and making it referenceable later. OTOH
setting the jcr:uuid property on a referenceable node is prohibited by the
spec.
AFAICS the overall intention here is to not allow modifications of jcr:uuid on
referenceable nodes as this will mess with referenceable integrity. The only
way to enforce that is to make jcr:uuid protected for mix:referenceable, which
has the side effect that it also cannot be set to an initial value unless going
through that loophole of first setting jcr:uuid end then making the node
referenceable. In any case there is no harm done here only a bit of oddness.
> Inconsistent protected property validation on mixin
> ---------------------------------------------------
>
> Key: OAK-2121
> URL: https://issues.apache.org/jira/browse/OAK-2121
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
> Reporter: Alex Parvulescu
> Assignee: Michael Dürig
> Attachments: NodeTypeTest.java.patch
>
>
> I ran into an inconsistent validation of the node's properties depending on
> where the mixin is set:
> this correctly fails on the #setProperty method
> {code}
> n.addMixin(JcrConstants.MIX_REFERENCEABLE);
> n.setProperty("jcr:uuid", UUID.randomUUID().toString());
> session.save();
> {code}
> this works:
> {code}
> n.setProperty("jcr:uuid", UUID.randomUUID().toString());
> n.addMixin(JcrConstants.MIX_REFERENCEABLE);
> session.save();
> {code}
> Shouldn't the check still happen on save in the second case?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
