Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <25792982.75731286802936349.JavaMail.jira@thor>
Date: Mon, 11 Oct 2010 09:15:36 -0400 (EDT)
From: "Stefan Guggisberg (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Resolved: (JCR-1867) Missing conflict when adding a mixin,
 whose protected items have been manually added before
In-Reply-To: <63043851.1227113744290.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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
                   2.0-alpha1

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 before
> -------------------------------------------------------------------------------------------
>
>                 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 validation.

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