jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3629) [jcr2spi]RepositoryException lost in org.apache.jackrabbit.jcr2spi.ItemManagerImpl while querying on remote nodes exposed by jackrabbit-spi
Date Thu, 25 Jul 2013 12:47:48 GMT

    [ https://issues.apache.org/jira/browse/JCR-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719581#comment-13719581

angela commented on JCR-3629:

jcr2spi doesn't run any test. please run a complete build of all of jackrabbit with -PintegrationTesting.
this will run all tests for all jcr2spi - spi2something setup scenarios present in jackrabbit
core including the jcr-remoting.

regarding public and non-public API: you kept struggling with that distinction in the past
when adding functionality to sling that used internal, non-public API.
it's very simple: everything in jackrabbit-api and jackrabbit-spi is public API everything
else is internal API and may change any time.
> [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
>         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 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

View raw message