[
https://issues.apache.org/jira/browse/OAK-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14170993#comment-14170993
]
Chetan Mehrotra commented on OAK-2052:
--------------------------------------
In some case if there is an error while creating the Value from InputStream
then that gets wrapped in ErrorValue. With current code in branch that
exception would get lost as the instanceof check would fail. With this fix that
exception would be surfaced and user would get to know the root cause.
So possibly it would be good to merge it to 1.0 branch.
[~tripod] [~mduerig] Thoughts?
> 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
> Fix For: 1.1.0
>
>
> 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.3.4#6332)
