Possible bug in TCK test WorkspaceCloneReferenceableTest.testCloneNodesRemoveExistingFalse

["McComsey, Doug" <Do...@ca.com>]

I think I found a bug in WorkspaceCloneReferenceableTest.testCloneNodesRemoveExistingFalse but I would like a second opinion.

When I run the test I fail with an ItemExistsException on the first clone statement, as follows.

public void testCloneNodesRemoveExistingFalse() throws RepositoryException {
    // add mixin referenceable to node1
    addMixinReferenceableToNode(node1);

    // clone a node from default workspace to have the same uuid on second workspace
    workspaceW2.clone(workspace.getName(), node1.getPath(), testRootNodeW2.getPath() + "/" + nodeName2, false);
*** I fail on the above

    // clone node1 from default workspace to second workspace
    try {
        workspaceW2.clone(workspace.getName(), node1.getPath(), testRootNodeW2.getPath() + "/" + nodeName3, false);
        fail("If removeExisting is false then a UUID collision should throw a ItemExistsException");
    } catch (ItemExistsException e) {
        // successful
    }
}

Upon examination I notice that node1 and node2 are created in both workspaces by the setUp code. Therefore, I would expect the first clone to fail.

1. Am I seeing this correctly? 
2. Does the test have a bug? 
3. Should the first clone be removed since it appears to have already been done?

Doug McComsey
Computer Associates
doug.mccomsey@ca.com
 

Re: Possible bug in TCK test WorkspaceCloneReferenceableTest.testCloneNodesRemoveExistingFalse

[Marcel Reutegger <ma...@gmx.net>]

Hi Doug,

McComsey, Doug wrote:
> I think I found a bug in WorkspaceCloneReferenceableTest.testCloneNodesRemoveExistingFalse but I would like a second opinion.
> 
> When I run the test I fail with an ItemExistsException on the first clone statement, as follows.
> 
> public void testCloneNodesRemoveExistingFalse() throws RepositoryException {
>     // add mixin referenceable to node1
>     addMixinReferenceableToNode(node1);
> 
>     // clone a node from default workspace to have the same uuid on second workspace
>     workspaceW2.clone(workspace.getName(), node1.getPath(), testRootNodeW2.getPath() + "/" + nodeName2, false);
> *** I fail on the above
> 
>     // clone node1 from default workspace to second workspace
>     try {
>         workspaceW2.clone(workspace.getName(), node1.getPath(), testRootNodeW2.getPath() + "/" + nodeName3, false);
>         fail("If removeExisting is false then a UUID collision should throw a ItemExistsException");
>     } catch (ItemExistsException e) {
>         // successful
>     }
> }
> 
> Upon examination I notice that node1 and node2 are created in both workspaces by the setUp code. Therefore, I would expect the first clone to fail.
> 
> 1. Am I seeing this correctly? 
> 2. Does the test have a bug? 
> 3. Should the first clone be removed since it appears to have already been done?

yes and yes ;)

but no to the third question. The setUp() method copied the nodes which 
is different from cloning a node. When a node is copied it gets a new 
UUID, whereas it keeps the UUID when it is cloned.

we didn't have the problem in jackrabbit because our implementation 
supports same-name siblings. I've changed the test case that it does not 
  try to create same-name siblings. svn revision is: 291163

let me know if that works for you and thanks for reporting this issue.

regards
  marcel