You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Michael Dürig (JIRA)" <ji...@apache.org> on 2014/08/28 11:49:58 UTC

[jira] [Assigned] (OAK-2052) Node.setProperty(String, Value) fails for binary non ValueImpls

     [ https://issues.apache.org/jira/browse/OAK-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Dürig reassigned OAK-2052:
----------------------------------

    Assignee: Michael Dürig

> Node.setProperty(String, Value) fails for binary non ValueImpls
> ---------------------------------------------------------------
>
>                 Key: OAK-2052
>                 URL: https://issues.apache.org/jira/browse/OAK-2052
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>            Reporter: Tobias Bocanegra
>            Assignee: Michael Dürig
>
> JCRVLT-58 reports an issue where "copying" of a JCR value fails,
> because the source and destination repository implementation are
> different.
> so basically:
> {code}
> 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());
> {code}
> AFAICT, this usually works but not for binary values. it eventually fails in:
> {code}
> 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();
>     }
> {code}
> ...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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)