Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Tue, 3 Jul 2012 12:51:20 +0000 (UTC)
From: "Julian Reschke (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: <661807375.56.1341319880380.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <1900401003.795.1341280846273.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (JCR-3371) TCK test for shareable nodes
 incorrectly assumes the 'mix:shareable' mixin cannot be removed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Julian Reschke commented on JCR-3371:
-------------------------------------

Optimally, the test checks that when removeMixin succeeds, the node indeed isn't shareable anymore. Can you suggest a patch that does this and works for your repository?
                
> TCK test for shareable nodes incorrectly assumes the 'mix:shareable' mixin cannot be removed
> --------------------------------------------------------------------------------------------
>
>                 Key: JCR-3371
>                 URL: https://issues.apache.org/jira/browse/JCR-3371
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-jcr-tests, JCR 2.0, test
>    Affects Versions: 2.5
>            Reporter: Randall Hauch
>            Priority: Critical
>             Fix For: 2.5.1, 2.6
>
>
> The ShareableNodeTest.testRemoveMixin() assumes that removing the "mix:shareable" mixin will *always* throw an UnsupportedOperationException. This is not only checking for the incorrect exception, section 14.15 "RemoveMixin" specifically states that it *is* possible for an implementation to support removing the 'mix:shareable' mixin:
>    "If an attempt is made to remove the mix:shareable mixin node type from a node in a 
>     shared set the implementation may either throw a ConstraintViolationException or allow 
>     the removal and change the subgraph in some implementation-specific manner. 
>     One possibility is to replace the node with a copy that has no children (if this does not 
>     violate the node type restrictions of that node). Another possibility is to give the node 
>     a copy of all of its descendants (unless the resulting copy operation would be unfeasible, 
>     as would be the case if a share cycle were involved)."
> Thus, even though it is possible for an implementation not to allow removing the "mix:shareable" mixin, the test shouldn't expect that an implementation will throw an exception. For example, one particularly easy thing for an implementation to support is removing 'mix:shareable' if and only if there are no other shared nodes (e.g., the "getSharedSet().getSize() == 1").
> This test could be removed, or perhaps it might be possible to test that removing the mixin (and saving) will either succeed or will throws only a ConstraintViolationException.
> I marked as critical because the TCK test prevents other implementations from correctly proving compatibility.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira