[ http://issues.apache.org/jira/browse/JCR-682?page=all ]
Dominique Pfister closed JCR-682. --------------------------------- > 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
