* Do not put span context into go context if extraction failed
This causes problems if multiple trace propagators are chained,
because the first propagator in chain may extract a valid span
context, then next propagator will overwrite it with an empty span
context when required headers in supplier are missing.
* Test for clobbering propagators
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
* TraceID and SpanID implementations for Stringer Interface
* Hex encode while stringifying
* Modify format specifiers wherever SpanID is used
* comment changes
* Remove TraceIdString() and SpanIdString()
* Comments Fixes
* Update License header for all source files
- Add Apache 2.0 header to source files that did not have one.
- Update all existing headers dated to 2019 to be 2020
- Remove comma from License header to comply with the Apache 2.0
guidelines.
* Update Copyright notice
Use the standard Copyright notices outlined by the
[CNCF](https://github.com/cncf/foundation/blob/master/copyright-notices.md#copyright-notices)
* Add global propagators
The default global propagators are set to the chained W3C trace and
correlation context propagators.
* Use global propagators in plugins
The httptrace and grpcplugins should also get some API for setting a
propagator to use (the othttp plugin already has such an API), but
that can come in some other PR.
* Decrease indentation in trace propagators
* Drop obsolete TODOs
Now we do "something" with correlation context - it ends up in the
context, and we put the context into the request, so the chained HTTP
handler can access it too.
The other TODO was about tag.Upsert which is long gone.
* Do not unnecessarily update the request context
The request context already contains the span (and we add some
attribute there), so inserting it into context again is pointless.
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
* Remove binary propagators
They are in process of being dropped from the specification and we
haven't be using them anywhere in the project. Can reintroduce them
later.
* Rename Supplier to HTTPSupplier
The supplier is used only in HTTP propagators currently. It's not
clear if it will be useful for binary propagators if they get to be
specified at some point.
* Rework propagation interfaces
The biggest change here is that HTTP extractors return a new context
with whatever information the propagator is able to retrieve from the
supplier. Such interface does not hardcode any extractor's
functionality (like it was before by explicitly returning a span
context and correlation context) and makes it easy to chain multiple
propagators.
Injection part hasn't changed.
* Add Propagators interface
This interface (and its default implementation) is likely going to be
the propagation API used the most. Single injectors, extractors or
propagators are likely going to be used just as parameters to the
Option functions that configure the Propagators implementation.
* Drop noop propagator
It's rather pointless - just create an empty Propagators instance.
* Fix wrong name in docs
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
* Rename distributedcontext package to correlation
Correlation is the name we agreed upon.
* Move trace propagators to api/trace
The trace propagators tests had to be moved to a testtrace subpackage
to avoid import cycles between api/trace and internal/trace.
Needed to shut up golint about stutter in trace.TraceContext -
TraceContext is a name of a W3C spec, so this stutter is
expected. It's certainly still better than golint's suggestion of
having trace.Context.
* Rename api/propagators to api/propagation
This package will not contain any propagators in the long run, just
the interface definitions.
Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>
