Also looking at org.apache.jackrabbit.jcr2spi.ItemManager [1] the method signature for nodeExists, itemExists and propertyExists should have thrown RepositoryException just like other methods of the interface. But that not the case :( And changing that now is not an option
So best way to move forward would be to wrap it in RuntimeException [1] https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/ItemManager.java Chetan Mehrotra On Thu, Jul 25, 2013 at 1:16 PM, Chetan Mehrotra <[email protected]> wrote: > Hi Angela, > > But then returning false gives a wrong indication to the caller that > node/item does not exist and then it would cause issues in the > business logic implemented on top of that. So exception has to be > propagated upward. Now as method signature does not have the > RepositoryException then probably have to wrap it in some > RuntimeException. > > Chetan Mehrotra > > > On Thu, Jul 25, 2013 at 1:09 PM, Angela Schreiber <[email protected]> wrote: >> hi chetan >> >> i wouldn't do that as we generally avoid runtimeexceptions in jackrabbit. >> instead i would log an error. >> >> >> angela >> >> On 7/24/13 3:01 PM, "Chetan Mehrotra" <[email protected]> wrote: >> >>>Looking at the code [1] >>> >>> /** >>> * @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. Would it be fine to >>>do that? >>> >>>@abhinav - Can you open a bug for this? >>> >>>[1] >>>https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr2spi/src/mai >>>n/java/org/apache/jackrabbit/jcr2spi/ItemManagerImpl.java#L115 >>>Chetan Mehrotra >>> >>> >>>On Tue, Jul 23, 2013 at 7:42 PM, Abhinav Atul <[email protected]> wrote: >>>> Just in case if this would be the right place to find a solution. >>>>Please let me know if anything is unclear. >>>> >>>> Thanks >>>> Abhinav >>>> >>>> -----Original Message----- >>>> From: Abhinav Atul [mailto:[email protected]] >>>> Sent: 22 July 2013 14:58 >>>> To: Jackrabbit Users >>>> Subject: [jcr2spi] RepositoryException lost in ItemManager#nodeExists >>>> >>>> Hi, >>>> I am trying to implement a synchronization service >>>>using the jcr connector for Documentum. The issue I am facing is if the >>>>Documentum server becomes non-responsive while trying to check if a node >>>>has been updated or deleted at Documentum, the RepositoryException is >>>>lost in ItemManagerImpl#nodeExists and the synchronization service is >>>>communicated that the node does not exists which may not be the case. >>>>Could the RepositoryException be communicated further? >>>> >>>> Thanks >>>> Abhinav >>>> >>
