[
https://issues.apache.org/jira/browse/JCR-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated JCR-3629:
---------------------------------
Fix Version/s: 2.1.7
> [jcr2spi]RepositoryException lost in
> org.apache.jackrabbit.jcr2spi.ItemManagerImpl while querying on remote nodes
> exposed by jackrabbit-spi
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> 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
> Assignee: Chetan Mehrotra
> Fix For: 2.1.7, 2.7.1
>
> Attachments: JCR-3629.patch
>
>
> 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 was sent by Atlassian JIRA
(v6.1.4#6159)
