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

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Duplicate
• Fix Version/s: 1.6.2, 2.0-alpha1
• Component/s: jackrabbit-core
• Assignee: Unassigned
• Reporter: Angela Schreiber
• Created: 19/Nov/08 16:55
• Updated: 25/Jan/12 13:08
• Resolved: 23/Sep/11 14:37

Description

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.