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
Issue Type: Bug
Components: jackrabbit-core
Reporter: angela
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.
-
You can reply to this email to add a comment to the issue online.
