1. 16 Jul, 2018 1 commit
    • Jason Yellick's avatar
      FAB-10292 Update protobuf to v1.1.0 · 03104e71
      Jason Yellick authored
      
      
      Protobuf was slated to be updated already, but there is a long list of
      incompatibilities with the current source tree.
      
      Thi CR updates protobuf to v1.1.0, and addresses those
      incompatibilities.  Most of the changes are quite rote and fall into one
      of three buckets.
      
      1. Code which uses non-keyed field initialization.  (ie, initializing a
      struct like MyStruct{value1, value2, value3}).  The newer generated
      protos produces structs which have additional non-field members.
      Structs should always be initialized with named fields, regardless of
      whether they are protos or not.
      
      2. Code which assumes that reflect.DeepEqual between two protos with the
      same fields will return true.  This has never been the case, especially
      when considering protos with slice or map fields, but with proto v1.1.0
      with the addition of caching and other members to the proto structs, it
      is even less true.  The correct call is proto.Equal.
      
      3. Code which assumes that proto fails on bad inputs -- the proto spec
      has always stated that failure _may_ occur, not that it must.  Certain
      code would attempt to determine proto message type based on failure to
      unmarshal, which was unsafe in v1.0.0, but is even more likely to cause
      problems in v1.1.0.
      
      4. On average, half of gossip identity digests aren't valid UTF8 strings,
         and proto v1.1.0 now enforces UTF8 validity checks for string fields.
         Therefore, the field was converted to bytes.
      
      Change-Id: I74cc037903137705dbe3f4e27e34d1307596db3b
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
      03104e71
  2. 26 Jul, 2017 1 commit
    • Jason Yellick's avatar
      [FAB-5443] Have configtxlator emit default fields · 82c6675f
      Jason Yellick authored
      
      
      Currently, configtxlator outputs configs with default fields omitted.
      This means for instance that if a value has not been changed, its
      version at 0 is not printed.  Similarly, if there is no CRL defined, the
      CRL field is not printed.
      
      Based on multiple reports, this behavior seems to be more confusing than
      helpful.  This CR changes the code to turn the emit defaults flag on.
      
      Change-Id: I4b393f4eb0473fd3e7ee09b7db6ccc4ac7c1932c
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      82c6675f
  3. 02 Jun, 2017 1 commit
    • Jason Yellick's avatar
      [FAB-4107] Expose proto translator via REST · 5fb91b5b
      Jason Yellick authored
      
      
      As part of FAB-4100, there is a requirement to expose configuration
      utilities through a REST interface.
      
      This CR adds a proto-translator REST component.  Further documentation
      is pending, but the high level usage is:
      
      POST binary-proto to /protolator/decode/fq.MessageType replies with a
      deeply marshaled JSON version of the proto.
      
      POST json-doc to /protolator/encode/fq.MessageType replies with the
      proto version of the deeply marshaled JSON doc.
      
      Change-Id: I595b92b1c292d8d4d360b0bd4223b138615143ac
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      5fb91b5b