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] Reopened: (JCR-682) AccessManager + CachingHierarchyManager problem
Date Mon, 18 Dec 2006 19:08:23 GMT
     [ http://issues.apache.org/jira/browse/JCR-682?page=all ]

Jukka Zitting reopened JCR-682:

Reopening issue to edit metadata.

PS. When resolving issues, please just mark it as resolved but don't close it as there may
still be a need to edit the issue metadata  (a closed issue can't be edited) before a release.
Also, in general an issue shouldn't be considered closed until it has gone out in an official
release. See the initial Jira guidelines I recently sent to dev@.

> 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


View raw message