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