Abhinav Atul created JCR-3629:
---------------------------------
Summary: RepositoryException lost in ItemManagerImpl#nodeExists,
ItemManagerImpl#itemExists(HierarchyEntry), ItemManagerImpl#propertyExists,
ItemManagerImpl#itemExists(ItemState)
Key: JCR-3629
URL: https://issues.apache.org/jira/browse/JCR-3629
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-jcr2spi
Affects Versions: 2.5.3
Reporter: Abhinav Atul
/**
* @see ItemManager#nodeExists(Path)
*/
public boolean nodeExists(Path path) {
try {
// session-sanity & permissions are checked upon
itemExists(ItemState)
NodeState nodeState = hierMgr.getNodeState(path);
return itemExists(nodeState);
} catch (PathNotFoundException pnfe) {
return false;
} catch (ItemNotFoundException infe) {
return false;
} catch (RepositoryException re) {
return false;
}
}
The catch block for RepositoryException should probably wrap the exception as a
RuntimeException as it might happen for unknown reason.
Changing this might break backward compatibility.
The issue was detected when trying to implement a synchronization service with
a content repository exposed by a jackrabbit-spi implementation. If the content
repository becomes non-responsive while checking whether a node exists or not,
the RepositoryException is lost in ItemManager#nodeExists resulting in deletion
of the local node corresponding to the remote node.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
