[
https://issues.apache.org/jira/browse/JCR-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758809#action_12758809
]
Alexander Klimetschek edited comment on JCR-2321 at 9/23/09 11:13 AM:
----------------------------------------------------------------------
Added patch for the 1.4 branch that fixed the problem for me.
(In theory, this patch should work on the 1.5 and 1.6 branches as well)
was (Author: alexander.klimetschek):
Added patch for the 1.4 branch that fixed the problem for me.
> ZombieHierarchyManager can return wrong child node entries for replaced nodes
> -----------------------------------------------------------------------------
>
> Key: JCR-2321
> URL: https://issues.apache.org/jira/browse/JCR-2321
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: core 1.4.10, 1.5.7, 1.6.0, 2.0-alpha9
> Reporter: Alexander Klimetschek
> Priority: Minor
> Attachments: JCR-2321-branch-1.4.patch, JCR-2321-trunk.patch
>
>
> The ZombieHierarchyManager currently implements the two getChildNodeEntry
> methods like this:
> 1) look up child node in old, overlayed state, which might contain removed
> child nodes
> 2) if not found, ask the super implementation (ie. get the child node from
> the up-to-date list)
> The purpose of the ZombieHM is to be able to return removed item ids from the
> attic. However, the behavior above is IMO wrong, as it should first find an
> existing child node with the given name (or id):
> 1) look up child node in super implementation (ie. get the child node from
> the up-to-date list)
> 2) if not found, look in the old, overlayed state if it might have been
> removed
> I was able to reproduce this issue when replacing a node (but note the custom
> access manager in 1.4.x used as explained below): create /replaced/subnode
> structure, save the session, remove the replaced node and add /replaced and
> then /replaced/subnode again:
> Node rootNode = session.getRootNode();
>
> // 1. create structure /replaced/subnode
> Node test = rootNode.addNode("replaced", NT);
> test.addNode("subnode", NT);
> // 2. persist changes
> session.save();
> // 3. remove node and recreate it
> test.remove();
> test = rootNode.addNode("replaced", NT);
>
> // 4. create previous child with same name
> test.addNode("subnode", NT);
>
> // 5. => gives exception
> test.getNode("subnode").getNodes();
> To complicate things further, this was only triggered by a custom access
> manager, and all based upon Jackrabbit 1.4.x. Back then (pre-1.5 and new
> security stuff era), the access manager would get a ZombieHM as its hierarchy
> manager. If its implementation called resolvePath() on the HM for checking
> read-access in the final getNodes() call, where the tree will be traversed
> using the getChildNdeEntry(NodeState, Name, int) method, it would get the old
> node id and hence fail if it would try to retrieve it from the real item
> state manager.
> Thus with a Jackrabbit >= 1.5 and 2.0 the above code will work fine, because
> the ZombieHM is not used.
> However, we might want to fix it for 1.4.x and also check the other uses of
> the ZombieHM in the current trunk, which I couldn't test. These are (explicit
> and implicit): ChangeLogBasedHierarchyMgr,
> SessionItemStateManager.getDescendantTransientItemStates(NodeId),
> ItemImpl.validateTransientItems(Iterable<ItemState>, Iterable<ItemState>) and
> SessionItemStateManager.getDescendantTransientItemStatesInAttic(NodeId).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
