jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (JCR-682) AccessManager + CachingHierarchyManager problem
Date Mon, 18 Dec 2006 19:22:23 GMT
     [ http://issues.apache.org/jira/browse/JCR-682?page=all ]

Jukka Zitting resolved JCR-682.
-------------------------------

    Resolution: Fixed

Re-resolving. I merged the change also to the 1.2 branch, so this fix will be going out in
the upcoming 1.2 release.

> 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, 1.1, 1.0.1, 1.0, 0.9
>            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