without this change any exception that is not caught by a filter, get caught and logged by server's internals (e.g. Tomcat's Valve). To make the Valve log the exception together with the tracing information we would have to allow the tracing context remain in the thread after TraceFilter gets executed. That is problematic cause we're polluting the ThreadLocal and would have to assume that some component will eventually clear the context.
with this change we're trying to solve the issue from a different angle. Whenever an uncaught exception is thrown, we are already catching it in the `catch(...) {}` clause. It's enough to just log it at the error level and that way, regardless of the underlying server implementation (Tomcat, Undertow) we will log the uncaught exception and rethrow it.
fixes#714
Amazon will throw out trace IDs that aren't associated with a recent
timestamp. This encodes the current epoch seconds into the first 32
of a 128-bit trace ID to support conversion to an Amazon Root ID.
This adds the ability to opt out of span sharing between the client and
server side of an RPC. This is important when reporting to systems that
do not share span IDs, such as Google Stackdriver and Amazon X-Ray.
Amazon will throw out trace IDs that aren't associated with a recent
timestamp. This encodes the current epoch seconds into the first 32
of a 128-bit trace ID to support conversion to an Amazon Root ID.
whenever:
- a span or trace id get generated when a request / message arrives
- child span is created
we set the field to false
whenever we find ids in the incoming request / message we set the field to true
fixes#696
without this change we created a "fallback span" in the case where a Spring component didn't handle the span. By handling it means that it got processed by anyway (a tag, log was added etc.). Why did we do that? That's because if no component was involved in creation of additional spans then in the Zipkin UI the service that had only the span that has the SR, SS logs wouldn't show up. In other words, if service A called service B and service B had only a single span, then service B wouldn't show up in the UI (there would be no blue bar). All the data would show up however in the client side of that span.
with this change we're removing this behaviour. That's because it introduces confusion for our users, that use non Spring related components. Also it seems that the Zipkin UI got fixed and this error no longer is present. If however it turns out that it's still there, it clearly seems that the place to fix this error should be Zipkin and not Sleuth.
fixes#708
whenever:
- a span or trace id get generated when a request / message arrives
- child span is created
we set the field to false
whenever we find ids in the incoming request / message we set the field to true
fixes#696
without this change we don't know which class or method (if the SpanCreator got overridden) was annotated
with this change we're adding the tags with this info
fixes#690
without this change you have to add a `@Primary` annotation around your custom `TraceFilter` bean to alter the behaviour of the current `TraceFilter` implementation
with this change we're marking the `TraceFilter` as conditional on missing bean; also we're ensuring that the registered `SkipPatternProvider` will be reused when no explicit pattern was set.
also documentation is added
fixes#633
