You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Tobias Bocanegra <tr...@apache.org> on 2014/08/26 07:14:09 UTC

JCR API implementation transparency

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(....);
n2 = s2.getNode(....);

n2.setProperty(p1.getName(), p1.getValue());

AFAICT, this usually works but not for binary values. it eventually fails in:

org.apache.jackrabbit.oak.plugins.value.ValueImpl#getBlob(javax.jcr.Value)

    public static Blob getBlob(Value value) {
        checkState(value instanceof ValueImpl);
        return ((ValueImpl) value).getBlob();
    }

...because the value is not a ValueImpl but a QValue.

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?

Regards, Toby


[0] https://issues.apache.org/jira/browse/JCRVLT-58

Re: JCR API implementation transparency

Posted by Michael Dürig <md...@apache.org>.

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

Re: JCR API implementation transparency

Posted by Tobias Bocanegra <tr...@apache.org>.
fyi, I created https://issues.apache.org/jira/browse/OAK-2052

On Mon, Aug 25, 2014 at 10:32 PM, Chetan Mehrotra
<ch...@gmail.com> wrote:
> On Tue, Aug 26, 2014 at 10:44 AM, Tobias Bocanegra <tr...@apache.org> 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

Posted by Chetan Mehrotra <ch...@gmail.com>.
On Tue, Aug 26, 2014 at 10:44 AM, Tobias Bocanegra <tr...@apache.org> 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