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-4317] Fix go 1.7 uint32 parsing in protolator · ead51986
      Jason Yellick authored
      
      
      Under go 1.7, the defaults for JSON unmarshaling are different than for
      go 1.8.  In particular, go 1.7 unmarshals numbers to the float64 type by
      default, while go 1.8 unmarshals numbers to the json.Numeric type (which
      stores both an int64 and float64 representation).
      
      The float64 numbers cannot be converted to uint32 fields in the proto
      structures, causing an error in decoding.
      
      This CR switches from using the default json.Unmarshal method to a
      custom json.Decoder to achieve the go 1.8 behavior in go 1.7.
      
      Change-Id: I1d3a980f116dddb1749dc9110ffb4a94f2cc105c
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      ead51986
  4. 26 May, 2017 5 commits
    • Jason Yellick's avatar
      [FAB-4103] Proto translator variably opaque comp · 7b5b661b
      Jason Yellick authored
      
      
      The proto translation framework introduced in FAB-4100 needs to be
      applied to messages with opaque fields.  This is one of the key goals of
      proto translation, which prevents the protos as defined from being human
      readable.
      
      This CR adds a variably opaque proto msg handler to the proto
      translation framework.  Documented further in api.go, but variably
      opaque fields differ from statically opaque ones, in that variably
      oapque fields may depend upon the contents of the proto being populated
      to determine type information at runtime and will be evaluated after the
      static ones.
      
      Change-Id: Iacbba1316f8e82dee68695aa98bf4c30a1a139da
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      7b5b661b
    • Jason Yellick's avatar
      [FAB-4102] Proto translator statically opaque comp · 7fd6a909
      Jason Yellick authored
      
      
      The proto translation framework introduced in FAB-4100 needs to be
      applied to messages with opaque fields.  This is one of the key goals of
      proto translation, which prevents the protos as defined from being human
      readable.
      
      This CR adds a statically opaque proto msg handler to the proto
      translation framework.
      
      Change-Id: Ifebc46f3bd3ec2087a9f2d579de30da5a3cb784d
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      7fd6a909
    • Jason Yellick's avatar
      [FAB-4101] Proto translator nested msg component · 5a94f1a0
      Jason Yellick authored
      
      
      The proto translation framework introduced in FAB-4100 needs to be
      recursively applied to sub-messages within proto messages.
      
      This CR adds a nested proto msg handler to the proto translation
      framework.
      
      Change-Id: Ib992908c431a1c5fe376b44070dec32a4b675675
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      5a94f1a0
    • Jason Yellick's avatar
      [FAB-4100] Create proto translator framework · de54331e
      Jason Yellick authored
      
      
      Doing bidirectional proto translation to/from deep JSON representation
      requires a significant amount of dynamic programming. Having each
      message try to to handle this work independently is a recipe for
      disaster, so the bulk of the reflection work needs to be centralized so
      that protos may be simply extended with methods which drive the proto
      translation framework.
      
      This CR creates the base framework for handling the deep
      Marshaling/Unmarshaling of all types of proto messages.  For
      reviewability, it does not include any type implementations, so look for
      the implementations in subsequent CRs.
      
      The package is named protolator as a portmanteau of protobuf and
      translator.  Once the component pieces are checked in and the fabric
      protos annotated with the necessary helper methods, this framework will
      be capable of printing arbitrary fabric protos in a human readable way
      (ie Blocks, Envelopes, Config).
      
      Change-Id: I36703bdf8d2fb893477fcca5f56b671ca8e3659e
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      de54331e
    • Jason Yellick's avatar
      [FAB-4104] Proto translator dynamic field comp · 7c4fcbf3
      Jason Yellick authored
      
      
      The proto translation framework introduced in FAB-4100 needs to be
      applied to messages with dynamic fields.  Dynamic fields are fields
      whose message may need to be unmarshaled differently depending on
      context.
      
      For instance, different ConfigValue messages may resolve the same field
      to different types, depending on the context in which the ConfigValue is
      evaluated.
      
      This CR adds a dynamic proto msg handler to the proto translation
      framework.
      
      Change-Id: I4bf809721f9af37778aeb3df3d706bfda1ed4e7b
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      7c4fcbf3