jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Michele (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1773) shareable nodes: wrong path returned, causes remove() to delete wrong node
Date Fri, 24 Apr 2009 14:29:30 GMT

    [ https://issues.apache.org/jira/browse/JCR-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702389#action_12702389

Lars Michele commented on JCR-1773:

The main problem on this issue is, that "b1" and the "item" hold a reference on the same node
implementation "NodeImpl". Even if you change the underlying item state when retrieving the
item with session.getItem(path), p.equals(b1.getPath()) would always be true. A quick workaround
for being sure to delete the right node of the shared set would be a change in ItemManager#getItemData(ItemId
itemId, Path path, boolean permissionCheck). If you call something like session.getItem(path).remove()
the right node would be deleted from the shared set.

private ItemData getItemData(ItemId itemId, Path path, boolean permissionCheck)
            throws ItemNotFoundException, AccessDeniedException,
            RepositoryException {
        ItemData data = retrieveItem(itemId);
        if (data == null) {
            // not yet in cache, need to create instance:
            // - retrieve item state
            // - create instance of item data
            // NOTE: permission check & caching within createItemData
            ItemState state;
            try {
                state = itemStateProvider.getItemState(itemId);
            } catch (NoSuchItemStateException nsise) {
                throw new ItemNotFoundException(itemId.toString());
            } catch (ItemStateException ise) {
                String msg = "failed to retrieve item state of item " + itemId;
                log.error(msg, ise);
                throw new RepositoryException(msg, ise);
            // create item data including: perm check and caching.
            data = createItemData(state, path, permissionCheck);
        } else {
            // already cached: if 'permissionCheck' is true, make sure read
            // permission is granted.
            if (permissionCheck && !canRead(data, path)) {
                // item exists but read-perm has been revoked in the mean time.
                // -> remove from cache
                throw new AccessDeniedException("cannot read item " + data.getId());
        // XXX Just a dirty workaround. It deals not with the core issue
	if (path != null && data instanceof NodeData) {
		NodeData nodeData = (NodeData) data;
		NodeState ns = (NodeState) nodeData.getState();
		if (ns.isShareable()) {
			NodeId parentId = hierMgr.resolveNodePath(path.getAncestor(1));
        return data;

So, a problem that lasts is, taking the the testPath() example from above, after getting "item,"
item.remove() and b1.remove() would remove both the node at "/a1/a2/b2", what is not expected.

> shareable nodes: wrong path returned, causes remove() to delete wrong node
> --------------------------------------------------------------------------
>                 Key: JCR-1773
>                 URL: https://issues.apache.org/jira/browse/JCR-1773
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>            Reporter: Julian Reschke
> It seems that for shareable nodes it can happen that getPath() returns the wrong path
(one of another node in the shared set):
> /**
> * Verify that shared nodes return correct paths.
> */
> public void testPath() throws Exception {
>    Node a1 = testRootNode.addNode("a1");
>    Node a2 = a1.addNode("a2");
>    Node b1 = a1.addNode("b1");
>    b1.addMixin("mix:shareable");
>    testRootNode.save();
>    //now we have a shareable node N with path a1/b1
>    Session session = testRootNode.getSession();
>    Workspace workspace = session.getWorkspace();
>    String path = a2.getPath() + "/b2";
>    workspace.clone(workspace.getName(), b1.getPath(), path, false);
>    //now we have another shareable node N' in the same shared set as N with path a1/a2/b2
>    //using the path a1/a2/b2, we should get the node N' here
>    Item item = session.getItem(path);
>    String p = item.getPath();
>    assertFalse("unexpectedly got the path from another node from the same shared set
", p.equals(b1.getPath()));
> } 
> Note that when this happens, a subsequent remove() deletes the wrong node.
> (Thanks Manfred for spotting this one).

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message