hi chetan the ItemManager is an internal interface which can be changed. but i really don't want you to change the behavior and throw a runtime exception without a very detailed analysis of the impact.
kind regards angela On 7/25/13 9:54 AM, "Chetan Mehrotra" <[email protected]> wrote: >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/mai >n/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 >>>>> >>>
