jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Pitfield (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-509) TCK: NodeTest#testNodeIdentity fails if versioning and locking not supported
Date Thu, 03 Aug 2006 00:18:14 GMT
    [ http://issues.apache.org/jira/browse/JCR-509?page=comments#action_12425410 ] 
            
David Pitfield commented on JCR-509:
------------------------------------

> Is there a section in the specification that talks about those two methods and allows
them to throw an exception in such a case?

Since these methods are introduced in Section 8, "Optional Repository Features", I assumed
an implementation not supporting those features would throw UnsupportedRepositoryOperationException.

If an existing repository natively supported versioning and locking, but those features could
not be or were not exposed through JCR, it would be misleading to hardcode isCheckedOut to
return true and isLocked to return false.

Perhaps as a compromise, the test could call these methods unconditionally as it currently
does, but throw NotExecutableException if  the methods throw an UnsupportedRepositoryOperationException.

> TCK: NodeTest#testNodeIdentity fails if versioning and locking not supported
> ----------------------------------------------------------------------------
>
>                 Key: JCR-509
>                 URL: http://issues.apache.org/jira/browse/JCR-509
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: test
>            Reporter: David Pitfield
>
> The test calls isCheckedOut and isLocked without testing whether versioning and locking
are supported.
> Proposal: call isCheckedOut only if versioning is supported; call isLocked only if locking
is supported.
> --- NodeTest.java       (revision 422074)
> +++ NodeTest.java       (working copy)
> @@ -757,8 +769,12 @@
>          // check if they have the same child
>          assertEquals("Two references of same node have different children", testNode1.getNode(nodeName1),
testNode2.getNode(nodeName1));
>          // check state methods
> -        assertEquals("Two references of same node have different State for Node.isCheckedOut()",
testNode1.isCheckedOut(), testNode2.isCheckedOut());
> -        assertEquals("Two references of same node have different State for Node.isLocked()",
testNode1.isLocked(), testNode2.isLocked());
> +        if (isSupported(Repository.OPTION_VERSIONING_SUPPORTED)) {
> +          assertEquals("Two references of same node have different State for Node.isCheckedOut()",
testNode1.isCheckedOut(), testNode2.isCheckedOut());
> +        }
> +        if (isSupported(Repository.OPTION_LOCKING_SUPPORTED)) {
> +          assertEquals("Two references of same node have different State for Node.isLocked()",
testNode1.isLocked(), testNode2.isLocked());
> +        }
>          assertEquals("Two references of same node have different State for Node.isModified()",
testNode1.isModified(), testNode2.isModified());
>          assertEquals("Two references of same node have different State for Node.isNew()",
testNode1.isNew(), testNode2.isNew());
>          assertEquals("Two references of same node have different State for Node.isNode()",
testNode1.isNode(), testNode2.isNode());

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message