[MDSAL-273] Binding Data Codec: Java Implementation is not compatible with Binding DataObject Proxy for binary type Created: 06/Jul/17  Updated: 09/Mar/18  Resolved: 26/Jan/18

Status: Resolved
Project: mdsal
Component/s: None
Affects Version/s: None
Fix Version/s: Carbon

Type: Bug
Reporter: wu sandi Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


External issue ID: 8806

 Description   

The java Implementation is not compatible with the corresponding binding dataObject proxy for binary type.
It means that if a XX DataObject is constructed using its XXBuilder, you use its getter method to get the binay type value, the cloned byte[] is returned.
If the dataObject is retrieved from datastore with databroker, the dataobject is a proxy of NormalizdeNode,and you use its getter method to get the binay type value, the real byte[] reference is returned which is the same reference as the one in NormalizdeNode.
Now if you changed the byte[] reference such as the value of index 1, now the original NormalizdeNode will be affected. Is this a bug? Is the behavior desired? I think it should be the same behavior both of the java Implementation and the binding dataObject proxy.

The reason bebind this behavior is that the ValueTypeCodec for binay type is NOOP_CODEC, whose source code is below:
/**
*

  • No-op Codec, Java YANG Binding uses same types as NormalizedNode model
  • for base YANG types, representing numbers, binary and strings.
    *
    *
    */
    public static final SchemaUnawareCodec NOOP_CODEC = new SchemaUnawareCodec() {

@Override
public Object serialize(final Object input)

{ return input; }

@Override
public Object deserialize(final Object input) { return input; }

};

As shown above, all of number and binary and string type all use NOOP_CODEC, but number and string is invariant, but the representation of binary type is byte array which is variant.

The bug is a back door to change the value of binary type?



 Comments   
Comment by wu sandi [ 06/Jul/17 ]

In addition, although the byte array is changed for binay type, the hashCode of the NormalizedNode which owns the binary type is not changed. So its a little strange, the value changed but the hashCode not changed.

Comment by wu sandi [ 06/Jul/17 ]

In addition, the java type of the container node is ImmutableContainerNode. It is immutable, but due to binary type, it seems to be mutable(real changed, but its hashcode is not changed). Much more strange!

Comment by Martin Ciglan [ 10/Jul/17 ]

quite busy now, will check this out later on and respond... leaving UNCONFIRMED

Comment by Robert Varga [ 26/Jan/18 ]

Fixed in yangtools via https://git.opendaylight.org/gerrit/61464.

Generated at Wed Feb 07 20:09:19 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.