You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Abhinav Atul <aa...@adobe.com> on 2013/07/23 16:12:48 UTC
FW: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
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:aatul@adobe.com]
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
Re: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Thu, Jul 25, 2013 at 1:39 PM, Angela Schreiber <an...@adobe.com> wrote:
> the ItemManager is an internal interface which can be changed.
Ah ... did not realized that its an internal interface. Fine then we
can change its method signature to throw RepositoryException. Makes
sense
Chetan Mehrotra
Re: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
Posted by Michael Dürig <md...@adobe.com>.
Same concerns here. Probably all/most callers of that method already
throw a RepositoryException. So changing that internal interface would
be the better option IMO.
Michael
On 25.7.13 10:09, Angela Schreiber wrote:
> 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" <ch...@gmail.com> 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
>> <ch...@gmail.com> 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 <an...@adobe.com>
>>> 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" <ch...@gmail.com>
>>>> 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 <aa...@adobe.com> 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:aatul@adobe.com]
>>>>>> 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
>>>>>>
>>>>
>
Re: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
Posted by Angela Schreiber <an...@adobe.com>.
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" <ch...@gmail.com> 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
><ch...@gmail.com> 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 <an...@adobe.com>
>>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" <ch...@gmail.com>
>>>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 <aa...@adobe.com> 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:aatul@adobe.com]
>>>>> 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
>>>>>
>>>
Re: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
Posted by Chetan Mehrotra <ch...@gmail.com>.
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
<ch...@gmail.com> 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 <an...@adobe.com> 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" <ch...@gmail.com> 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 <aa...@adobe.com> 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:aatul@adobe.com]
>>>> 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
>>>>
>>
Re: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
Posted by Chetan Mehrotra <ch...@gmail.com>.
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 <an...@adobe.com> 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" <ch...@gmail.com> 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 <aa...@adobe.com> 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:aatul@adobe.com]
>>> 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
>>>
>
Re: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
Posted by Angela Schreiber <an...@adobe.com>.
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" <ch...@gmail.com> 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 <aa...@adobe.com> 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:aatul@adobe.com]
>> 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
>>
Re: FW: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
Posted by Chetan Mehrotra <ch...@gmail.com>.
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/main/java/org/apache/jackrabbit/jcr2spi/ItemManagerImpl.java#L115
Chetan Mehrotra
On Tue, Jul 23, 2013 at 7:42 PM, Abhinav Atul <aa...@adobe.com> 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:aatul@adobe.com]
> 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
>