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. 15 Sep, 2017 1 commit
  3. 06 Jun, 2017 1 commit
    • Jason Yellick's avatar
      [FAB-4418] Fix confusing policy naming · 5435d215
      Jason Yellick authored
      
      
      When traversing the JSON tree as generated by configtxlator, the
      following list of elements is encountered:
      
      policies -> <name> -> policy -> policy -> policy -> n_out_of -> policies
      
      This is understandably very confusing for users, as so many different
      elements claim to represent a policy.  This CR modifies the policy
      definitions so that instead that same list of elements becomes:
      
      policies -> <name> -> policy -> value -> rule -> n_out_of -> rules
      
      This makes it much more clear that the third element is a named policy,
      and that the policy has a value, consisting of a rule, which itself may
      be composed of other rules.
      
      The consumers of the existing name scheme are restricted to those users
      of configtxlator or those who have manually attempted to build these
      messages (I am unaware of any).  This is not an ABI breakage, although
      because of the nature of the bug it is an API breakage.
      
      Change-Id: Ia0d99f6e08ce43bc2563dc2caf9de9fd512af191
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      5435d215
  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