jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] Created: (JCR-1867) Missing conflict when adding a mixin, whose protected items have been manually added before
Date Wed, 19 Nov 2008 16:55:44 GMT
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
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);

        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


        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.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message