Uploaded image for project: 'Jackrabbit Content Repository'
  1. Jackrabbit Content Repository
  2. JCR-1867

Missing conflict when adding a mixin, whose protected items have been manually added before



    • Bug
    • Status: Closed
    • Major
    • Resolution: Duplicate
    • None
    • 1.6.2, 2.0-alpha1
    • jackrabbit-core
    • None


      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.

      i didn't test Node#setPrimaryType(String) but after all i would expected a corresponding validation.




            Unassigned Unassigned
            angela Angela Schreiber
            0 Vote for this issue
            0 Start watching this issue