[jira] [Resolved] (JCR-1867) Missing conflict when adding a mixin, whose protected items have been manually added before

["Jukka Zitting (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JCR-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting resolved JCR-1867.
--------------------------------

    Resolution: Duplicate

> Missing conflict when adding a mixin, whose protected items have been manually added before
> -------------------------------------------------------------------------------------------
>
>                 Key: JCR-1867
>                 URL: https://issues.apache.org/jira/browse/JCR-1867
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>            Reporter: angela
>             Fix For: 2.0-alpha1, 1.6.2
>
>
> with a unstructured node it is possible to manually create protected items of the jcr namespace such
> as e.g. jcr:uuid. while this obviously isn't recommended, but it currently works fine... 
> however i would expect that subsequently adding a mixin-type that defines those items (in the example mix:referenceable) would either
> - fail with constraintviolationexception or
> - at least redefine the items according to the mixin definition.
> test case for illustration of the problem that no only applies to jcr:uuid but to any protected item defined by a built-in or custom node type.
>     public void testConflictingJcrUUID() throws RepositoryException {
>         // adding a custom jcr:uuid property is definitely not recommended
>         // but it currently works...
>         Node n = testRootNode.addNode(nodeName1, JcrConstants.NT_UNSTRUCTURED);
>         n.setProperty(JcrConstants.JCR_UUID, true);
>         testRootNode.save();
>         assertTrue(n.hasProperty(JcrConstants.JCR_UUID));
>         assertFalse(n.isNodeType(JcrConstants.MIX_REFERENCEABLE));
>         Property p = n.getProperty(JcrConstants.JCR_UUID);
>         assertEquals(PropertyType.BOOLEAN, p.getType());
>         NodeType nt = p.getDefinition().getDeclaringNodeType();
>         assertEquals(JcrConstants.NT_UNSTRUCTURED, nt.getName());
>         // ... test effect of adding mix:referenceable now
>         n.addMixin(JcrConstants.MIX_REFERENCEABLE);
>         n.save();
>         assertTrue(n.isNodeType(JcrConstants.MIX_REFERENCEABLE));
>         assertEquals(PropertyType.STRING, p.getType());       <====== false. type is still 
>         UUID.fromString(p.getString());                                         <====== fails. value is still 'true'
>         nt = p.getDefinition().getDeclaringNodeType();               
>         assertEquals("mix:referenceable", nt.getName());       <====== false. declaring nt is still nt:unstructured
>     }
> in order to avoid unexpected (and maybe hard to analyze) behavior, i would prefer if 
> adding the mixin (or saving the changes) would fail in the first place indicating to the API
> user that existing content conflicts with the mixin to be added.
> btw:
> i didn't test Node#setPrimaryType(String) but after all i would expected a corresponding validation.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira