# Modules
* New modules: `spring-cloud-sleuth-autoconfigure`, `spring-cloud-sleuth-api`, `spring-cloud-sleuth-instrumentation`
`spring-cloud-sleuth-core` removed and changed to `spring-cloud-sleuth-instrumentation` & `spring-cloud-sleuth-api`
* Removed `spring-cloud-starter-sleuth-otel`
To add OpenTelemetry support you need to add `spring-cloud-starter-sleuth` (adds Brave by default), exclude Brave and add `spring-cloud-sleuth-otel` dependency
* Except for the tests, `spring-cloud-sleuth-autoconfigure` is the only module that can have access to `@Configuration`, `@ConfigurationProperties` classes.
Tests have been added to ensure such separation.
## Package moving
* `org.springframework.cloud.sleuth.api` -> `org.springframework.cloud.sleuth`
* `org.springframework.cloud.sleuth.brave.autoconfig` -> `org.springframework.cloud.sleuth.autoconfig.brave`
* `org.springframework.cloud.sleuth.otel.autoconfig` -> `org.springframework.cloud.sleuth.autoconfig.otel`
* `org.springframework.cloud.sleuth` -> `org.springframework.cloud.sleuth`
* Instrumentation: `org.springframework.cloud.sleuth.annotation` -> `org.springframework.cloud.sleuth.instrument.annotation`
* All the autoconfiguration classes were moved under `org.springframework.cloud/sleuth.autoconfig` package
## Global class modifications
* Any class registered as a bean is now public
## Classes
* `RateLimitingSampler` constructor changed
* Merged a lot of auto configuration classes into one (e.g. `BraveAutoConfiguration` now imports various other configurations)
* Renamed `TraceBraveAutoConfiguration` to `BraveAutoConfiguration`
* Renamed `TraceOtelAutoConfiguration` to `OtelAutoConfiguration`
* Removed all `NoOp` implementations of the API
Spring Cloud Sleuth currently is an autoconfiguration over Brave. It also consists of various instrumentation mechanisms for libraries that are not supported by Brave (e.g. Spring Cloud Circuitbreaker).
We would like to abstract Brave so that Spring Cloud Sleuth becomes an autoconfiguration for any tracer implementation that is compatible with Spring Cloud Sleuth. That way Spring Cloud Sleuth in its core module would consist of an API and various tracer implementations would implement that API which would also allow automatic instrumentation of libraries that are supported by Spring Cloud Sleuth.
## OpenTelemetry Support
Thanks to doing this abstraction we are able to support new tracer implementations, not only Brave. We've decided to add support for the OpenTelemetry SDK as the second one. If in the future if we decide to add new tracers then it will be just a matter of adding a new module that bridges to the Spring Cloud Sleuth one. Thanks to abstraction of tests as well we will be easily able to plug that tracer mechanism into our current suite of tests.
- adds Spring Cloud Function instrumentation
- adds Operators to manually provide instrumentation for Fluxes
- introduces Manual instrumentation mode for Reactor
TODO: Documentation (will add it soon)
related gh-1684
Brave's SpanHandler can report natively in other formats which have different
constraints than Zipkin and often extensions to the data model.
This change ports all tests away from Zipkin's types so that it is more clear
what's actually recorded vs what's a side-effect of Zipkin conversion.
This removes `BlockingQueueSpanReporter` which was never released, also.
without this change when an executor implementation was a final class or had a final method - the application wouldn't start or would produce NPE at startup.
with this change we have a custom bean post processor that wraps an aspect manualy either via a JDK Proxy when a class is final or a method is final or creates a CGLIB proxy if that's possible.
fixes#550
The main arguments for these features are
* api-agnostic means to collaborate with a span
- use of annotations allows users to add to a span with no library dependency on a span api.
This allows Sleuth to change its core api less impact to user code.
* reduced surface area for basic span operations.
- without this feature one has to use the span api, which has lifecycle commands that
could be used incorrectly. By only exposing scope, tag and log functionality, users can
collaborate without accidentally breaking span lifecycle.
* collaboration with runtime generated code
- with libraries such as Spring Data / Feign the implementations of interfaces are generated
at runtime thus span wrapping of objects was tedious. Now you can provide annotations
over interfaces and arguments of those interfaces
This PR is an adoption of @Koizumi85 work started here - https://github.com/Koizumi85/spring-cloud-sleuth-annotationfixes#182
