jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3524) Node type selection for reference constraint is not optimal
Date Wed, 20 Feb 2013 09:51:14 GMT

    [ 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

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

View raw message