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" <[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
