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 Sat, 25 Apr 2009 19:07:30 GMT

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

Lars Michele commented on JCR-1773:
-----------------------------------

Here comes now the hotfix for the WebDAV layer: 
 
 Change in org.apache.jackrabbit.webdav.simple.DavResourceImpl 
 
     /** 
      * @see DavResource#removeMember(DavResource) 
      */ 
     public void removeMember(DavResource member) throws DavException { 
         if (!exists() || !member.exists()) { 
             throw new DavException(DavServletResponse.SC_NOT_FOUND); 
         } 
         if (isLocked(this) || isLocked(member)) { 
             throw new DavException(DavServletResponse.SC_LOCKED); 
         } 
 
         // don't allow removal of nodes, that would be filtered out 
         if (isFilteredResource(member)) { 
             log.debug("Avoid removal of filtered resource: " + member.getDisplayName());

             throw new DavException(DavServletResponse.SC_FORBIDDEN); 
         } 
 
 
         try { 
             String itemPath = member.getLocator().getRepositoryPath(); 
             Item memItem = getJcrSession().getItem(itemPath); 
             //TODO once jcr2 is out: simply call removeShare() 
             if (memItem instanceof Node){ 
              Node memNode = getJcrSession().getRootNode().getNode(itemPath.substring(1));

              memNode.remove(); 
             }else if (memItem instanceof org.apache.jackrabbit.api.jsr283.Node) { 
                 org.apache.jackrabbit.api.jsr283.Node n = (org.apache.jackrabbit.api.jsr283.Node)
memItem; 
                 n.removeShare(); 
             } else { 
                 memItem.remove(); 
             } 
             getJcrSession().save(); 
 
             // make sure, non-jcr locks are removed, once the removal is completed 
             try { 
                 if (!isJsrLockable()) { 
                     ActiveLock lock = getLock(Type.WRITE, Scope.EXCLUSIVE); 
                     if (lock != null) { 
                         lockManager.releaseLock(lock.getToken(), member); 
                     } 
                 } 
             } catch (DavException e) { 
                 // since check for 'locked' exception has been performed before 
                 // ignore any error here 
             } 
         } catch (RepositoryException e) { 
             throw new JcrDavException(e); 
         } 
     } 
 
 A simple cast from Item to Node is not useable here, because the Session.getPath() does not
return the right node, if the node is shared. Btw, the memItem is never instance of org.apache.jackrabbit.api.jsr283.Node
here, but removeShare() is internally the same as remove() in JackRabbit.

> 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.


Mime
View raw message