jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] Commented: (JCR-2528) spi2dav: ItemInfoCache causes failure of (Workspace)RestoreTest#testRestoreWithUUIDConflict and variants
Date Thu, 04 Mar 2010 17:45:28 GMT

    [ 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.


Mime
View raw message