[ 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
