jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Pfister (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (JCR-682) AccessManager + CachingHierarchyManager problem
Date Mon, 18 Dec 2006 16:40:23 GMT
     [ 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

        

Mime
View raw message