You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Michael Dürig (JIRA)" <ji...@apache.org> on 2010/03/04 18:45:28 UTC

[jira] Commented: (JCR-2528) spi2dav: ItemInfoCache causes failure of (Workspace)RestoreTest#testRestoreWithUUIDConflict and variants

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

Michael Dürig commented on JCR-2528:
------------------------------------

The root cause of this is the move operation: when a referenceable node is moved to a new parent which is subsequently removed, the item info cache still contains the original NodeInfo (same uuid but old path) which causes this test failure. 

I propose to WorkspaceItemStateFactory.isUpToDate method such that it returns false for cases where the paths of the cached ItemInfo and the hierarchy entry do not match. After such cache entries are stale. 

> spi2dav: ItemInfoCache causes failure of (Workspace)RestoreTest#testRestoreWithUUIDConflict and variants
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JCR-2528
>                 URL: https://issues.apache.org/jira/browse/JCR-2528
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-jcr2spi, jackrabbit-spi2dav
>            Reporter: angela
>
> while running the API version tests i found the (Workspace)RestoreTest.testRestoreWithUUIDConfict and variants failing. to be precise the test passes but
> transiently removing the versionableNode2 in the teardown fails upon removal of the jcr:uuid property of the moved childnode.
> having a closer look at it revealed that the problem is caused in the WorkspaceItemStateFactory where the property entry is retrieved from the
> cache and subsequently checking if the path really matches fails. for test purposes i prevented the usage of the cached entry by returning false in WorkspaceItemStateFactory.isUpToDate  => the tests passed. 
> as far as i know the same tests pass with spi2jcr.
> michael, could it be that this is caused by a flaw in the iteminfo-cache logic? or is there something specific that needs to be adjusted in spi2dav?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.