jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chetan Mehrotra <chetan.mehro...@gmail.com>
Subject Re: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
Date Thu, 25 Jul 2013 07:54:13 GMT
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
<chetan.mehrotra@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 <anchela@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" <chetan.mehrotra@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 <aatul@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
>>>>
>>

Mime
View raw message