Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Wed, 20 Feb 2013 09:51:14 +0000 (UTC)
From: "angela (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: <JIRA.12632982.1361281122048.309661.1361353874763@arcas>
In-Reply-To: <JIRA.12632982.1361281122048@arcas>
References: <JIRA.12632982.1361281122048@arcas>
Subject: [jira] [Commented] (JCR-3524) Node type selection for reference
 constraint is not optimal
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JCR-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582058#comment-13582058 ] 

angela commented on JCR-3524:
-----------------------------

i would rather define one or a set of custom test node type(s) that provide the functionality required for the tests. 
assuming that a given node type is there is quite cumbersome in tck tests.

                
> Node type selection for reference constraint is not optimal
> -----------------------------------------------------------
>
>                 Key: JCR-3524
>                 URL: https://issues.apache.org/jira/browse/JCR-3524
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-jcr-tests
>            Reporter: Alex Parvulescu
>            Assignee: Alex Parvulescu
>            Priority: Minor
>         Attachments: JCR-3524.patch
>
>
> I've found 3 unit test that randomly choose a node type for a node that is supposed to break a reference constraint.
> The problem with the way the node type is selected is that the code could choose one that has itself some constraints (like nt:file for example). This can make the test pass for the wrong reason.
> Unfortunately having one exception for both test and failure to create a proper node structure (like in the case of an empty nt:file node) doesn't help with understanding what is happening, either.
> This came up in OAK-624, where the aforementioned behavior changed and the test started failing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira