jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Abhinav Atul (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (JCR-3629) [jcr2spi]RepositoryException lost in ItemManagerImpl#nodeExists, ItemManagerImpl#itemExists(HierarchyEntry), ItemManagerImpl#propertyExists, ItemManagerImpl#itemExists(ItemState)
Date Thu, 25 Jul 2013 07:03:50 GMT

     [ 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

Mime
View raw message