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
without this change when a CGLIB proxy fails to be created an exception is thrown
with this change we're trying to save the situation by trying to create a JDK proxy. If that also won't work then we're throwing an exception.
fixes#684
