Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <1492858590.1254328403488.JavaMail.jira@brutus>
Date: Wed, 30 Sep 2009 09:33:23 -0700 (PDT)
From: "Alexander Klimetschek (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Updated: (JCR-2321) ZombieHierarchyManager can return wrong
 child node entries for replaced nodes
In-Reply-To: <155895739.1253729235986.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/JCR-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Klimetschek updated JCR-2321:
---------------------------------------

    Affects Version/s:     (was: core 1.4.10)
                           (was: 2.0-alpha9)
                           (was: 1.5.7)
                           (was: 1.6.0)
                       2.0-alpha12

> 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.11, 1.5.7, 1.6.0, 2.0-alpha12
>            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.