JCR API implementation transparency

2014-08-25 Thread Tobias Bocanegra
Hi, I'm looking at an issue [0] where "copying" of a JCR value fails, because the source and destination repository implementation are different. so basically: s1 = repository1.login(); // remote repository via davex s2 = repository2.login(); // local oak repository p1 = s1.getProperty(); n

Re: JCR API implementation transparency

2014-08-25 Thread Chetan Mehrotra
On Tue, Aug 26, 2014 at 10:44 AM, Tobias Bocanegra wrote: > IMO, this should work, even if the value is not a ValueImpl. In this > case, it should fall back to the API methods to read the binary. +1 Chetan Mehrotra

Re: JCR API implementation transparency

2014-08-25 Thread Tobias Bocanegra
fyi, I created https://issues.apache.org/jira/browse/OAK-2052 On Mon, Aug 25, 2014 at 10:32 PM, Chetan Mehrotra wrote: > On Tue, Aug 26, 2014 at 10:44 AM, Tobias Bocanegra wrote: >> IMO, this should work, even if the value is not a ValueImpl. In this >> case, it should fall back to the API metho

Re: JCR API implementation transparency

2014-08-26 Thread Michael Dürig
On 26.8.14 7:14 , Tobias Bocanegra wrote: IMO, this should work, even if the value is not a ValueImpl. In this case, it should fall back to the API methods to read the binary. WDYT? Ack. This is most likely a regression introduces with OAK-1164. Michael