with this change the child span of the HTTP filter span gets changed into a span coming from the Controller aspect. The name of the span becomes the name of the method.
- Changed Random instantiation to a shared Random
- Changed the name of the converter
- Changed generator into random
- Span id is now non-nullable.
- it gets generated in the http filter if it's not there
- it's generated in the spring-integration channels if it wasn't set
Brave's span collector, which turned out to not be a great tool for
direct use. Brave internally creates spans before sending to its
collector, so validation is implicit. The flip side of this is using the
collector directly does not validate spans. This means it is easy to
send invalid ones, for example missing span names. The problem is more
difficult as the data is in binary (thrift).
This introduces HttpZipkinSpanReporter, which validates via zipkin-java
classes before sending on the wire. Moreover, this sends in json to make
debugging problems easier.
This does not fully remove the Brave dependency, as further work is
needed. Particularly, Brave is indirectly referenced in other code.
See https://github.com/openzipkin/zipkin-java/issues/68
See #98 (Reporter is an OpenTracing term)
It's not really necessary to use rabbit, but the existing tests
weren't really using the stream components at all because
zipkin spans were being collected by spring-cloud-sleuth-zipkin.
