[
https://issues.apache.org/jira/browse/JCR-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinav Atul updated JCR-3629:
------------------------------
Description:
RepositoryException lost in ItemManagerImpl#nodeExists,
ItemManagerImpl#itemExists(HierarchyEntry), ItemManagerImpl#propertyExists,
ItemManagerImpl#itemExists(ItemState)
/**
* @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.
was:
/**
* @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.
> [jcr2spi]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
>
> RepositoryException lost in ItemManagerImpl#nodeExists,
> ItemManagerImpl#itemExists(HierarchyEntry), ItemManagerImpl#propertyExists,
> ItemManagerImpl#itemExists(ItemState)
> /**
> * @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
