Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <22639057.1166460023137.JavaMail.jira@brutus>
Date: Mon, 18 Dec 2006 08:40:23 -0800 (PST)
From: "Dominique Pfister (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Resolved: (JCR-682) AccessManager + CachingHierarchyManager
 problem
In-Reply-To: <23064308.1166450841044.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/JCR-682?page=all ]

Dominique Pfister resolved JCR-682.
-----------------------------------

    Fix Version/s: 1.2
       Resolution: Fixed

Fixed as described: CachingHierarchyManager evicts its cache entry if it cannot detect the reordering of the child node entries that took place. Reran the test case and verified that it works. 

Fixed in r488325.

> AccessManager + CachingHierarchyManager problem
> -----------------------------------------------
>
>                 Key: JCR-682
>                 URL: http://issues.apache.org/jira/browse/JCR-682
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.1.1
>            Reporter: Roland Kofler
>         Assigned To: Dominique Pfister
>             Fix For: 1.2
>
>         Attachments: CachingHierarchManagerTest.zip
>
>
> The problem we have is the implementation of the CachingHierarchyManager,
> to which the SimpleAccessManager holds a reference.
> Let's consider following example:
> i add 3 subnodes (a,b,c) to a node and after that i reorder b and c ..
> so i have a,c,b. in the process of reordering (using the function
> orderBefore of javax.jcr.Node) our AccessManager is called several times to check the permissions of the nodes. In this AccessManager we use some
> functions of the CachingHierarchyManager, f.ex.
> Path itemPath = hierMgr.getPath(id);
> return itemPath.denotesRoot();
> or
> Path itemPath = hierMgr.getPath(itemId);
> Path parentPath = itemPath.getAncestor(1);
> return hierMgr.resolvePath(parentPath);
> the problem is, that when calling the methods of the
> CachingHierarchyManager the nodes i ask for will be cached in the idCache in a wrong state (i. e.: before actually reordering the elements).
> so if i want f.ex. delete the node b after reordering, the node will
> be looked up in the idCache. in the cache the index of node b is still 2
> (actually it should be 3) and so the wrong node will be deleted! 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira