jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (JCR-1867) Missing conflict when adding a mixin, whose protected items have been manually added before
Date Mon, 11 Oct 2010 13:15:36 GMT

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

Stefan Guggisberg resolved JCR-1867.

       Resolution: Fixed
    Fix Version/s: 1.6.2

non-reproducible on 2.2 trunk, most likely fixed through resolution of JCR-2170.

> Missing conflict when adding a mixin, whose protected items have been manually added
> -------------------------------------------------------------------------------------------
>                 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

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

View raw message