Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of anchela@adobe.com designates
 64.18.1.77 as permitted sender)
From: Angela Schreiber <anchela@adobe.com>
To: "dev@jackrabbit.apache.org" <dev@jackrabbit.apache.org>
Date: Thu, 25 Jul 2013 09:09:40 +0100
Subject: Re: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
Thread-Topic: [jcr2spi] RepositoryException lost in ItemManager#nodeExists
Thread-Index: Ac6JDk/8VlogfOrFTUSzkLC8nvT+ZQ==
Message-ID: <CE16A848.500C%anchela@adobe.com>
In-Reply-To: 
 <CAHCW-m=HmR47D-0iEpz5VyLgmVT=k+Yvp2rMnquiK0ToZo+x9g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.2.130206
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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" <chetan.mehrotra@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]=20
>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
><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 =3D 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
>>>>>
>>>