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.
Zipkin 0.4.1 obviates some duplication of configuration. It is also the
first version that's published as a docker image.
By switching to the published image of zipkin-java, we can be more
consistent, as `spring-cloud-sleuth-zipkin-stream` is derived from that,
not the scala query service.
Recent versions of zipkin and brave operate with http instead of scribe.
This changes the implementation accordingly, as well adds a sampler to
the POST endpoint.
A notable impact is that we no longer require a collector process, as
the zipkin server's POST endpoint is a collector.
- Merge branch 'master' of https://github.com/gauravrmazra/spring-cloud-sleuth into gauravrmazra-master
- Test scope removed for dependency. Needed for stomp message interceptor support
- Removed unused import from integration test
- Integration tests for TraceStompMessageContextChannelInterceptor
- Refactored code and added integration test for TraceStompMessageChannelInterceptor
- Fix for method which was not available in jdk1.7
- Fix build fail error due to new changes for stomp messages
- Support for STOMP messages over websocket
When a controller throws an exception the servlet container will
eventually set the response status to 500, but it is still 200
generally when the filter chain finishes, unless we catch the
exception and do something with it.
Fixes gh-57
