jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg von Frantzius (JIRA) <j...@apache.org>
Subject [jira] [Commented] (JCR-3239) Removal of a top level node doesn't update the hierarchy manager's cache.
Date Fri, 09 Nov 2012 15:42:13 GMT

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

Jörg von Frantzius commented on JCR-3239:

Also still exists in 2.4.1
> Removal of a top level node doesn't update the hierarchy manager's cache.
> -------------------------------------------------------------------------
>                 Key: JCR-3239
>                 URL: https://issues.apache.org/jira/browse/JCR-3239
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.2.11, 2.4
>            Reporter: Philipp Bärfuss
>            Priority: Minor
> *Problem*
> Scenario in which I encounter the problem:
> - given a node 'test' under root (/test)
> - re-imported the node after a deletion (all in-session operations) 
> {code}
> session.removeItem("/test")
> session.getImportXML("/", stream, ImportUUIDBehavior.IMPORT_UUID_COLLISION_THROW)
> {code}
> Result: throws an ItemExistsException
> If the same operations are executed deeper in the hierarchy (for instance /foo/bar) then
the code works perfectly fine.
> *Findings*
> - session.removeItem informs the hierachy manager (via listener)
> --> CachingHierarchyManager.nodeRemoved(NodeState, Name, int, NodeId)
> - but the root node (passed as state) is not in the cache and hence the entry of the
top level node is not removed
> --> CachingHierarchyManager: 458 
> - while trying to import the method SessionImporter.startNode(NodeInfo, List<PropInfo>)
calls session.getHierarchyManager().getName(id) (line 400)
> - the stall information causes a uuid collision (the code expects an exception if the
node doesn't exist but in this case it returns the name of the formerly removed node)
> Note: session.itemExists() and session.getNode() work as expected (the former returns
false, the later throws an ItemNotFound exception)
> Note: I know that a different import behavior (replace existing) would solve the issue
but I can't be 100% sure that the UUID match so I favor collision throw in my case.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message