SpringBoot WebClient- and RestTemplate-based Zipkin senders can cause a bean dependency cycle

without this change we're using a RestTemplate and WebClient beans for sending out spans. The same beans require Zipkin senders to be pre-configured through the tracing handlers. That's a cycle.

with this change we're breaking the cycle by not creating RT and WC as beans but we're creating them via new and we're providing customizers to allow RT and WC customization

Comment From: wilkinsona

Cycle:

The dependencies of some of the beans in the application context form a cycle:

   steepController defined in file [/home/marcin/repo/observability/projects/teahouse/tea-service/build/classes/java/main/org/example/teahouse/tea/controller/SteepController.class]
      ↓
   teaService defined in file [/home/marcin/repo/observability/projects/teahouse/tea-service/build/classes/java/main/org/example/teahouse/tea/service/TeaService.class]
      ↓
   defaultClientInterceptorProvider defined in org.springframework.cloud.openfeign.FeignClientsConfiguration$MetricsConfiguration
┌─────┐
|  observationRegistry defined in class path resource [org/springframework/boot/actuate/autoconfigure/observation/ObservationAutoConfiguration.class]
↑     ↓
|  defaultTracingObservationHandler defined in class path resource [org/springframework/boot/actuate/autoconfigure/tracing/MicrometerTracingAutoConfiguration.class]
↑     ↓
|  braveTracerBridge defined in class path resource [org/springframework/boot/actuate/autoconfigure/tracing/BraveAutoConfiguration.class]
↑     ↓
|  braveTracer defined in class path resource [org/springframework/boot/actuate/autoconfigure/tracing/BraveAutoConfiguration.class]
↑     ↓
|  braveTracing defined in class path resource [org/springframework/boot/actuate/autoconfigure/tracing/BraveAutoConfiguration.class]
↑     ↓
|  zipkinSpanHandler defined in class path resource [org/springframework/boot/actuate/autoconfigure/tracing/zipkin/ZipkinConfigurations$BraveConfiguration.class]
↑     ↓
|  spanReporter defined in class path resource [org/springframework/boot/actuate/autoconfigure/tracing/zipkin/ZipkinConfigurations$ReporterConfiguration.class]
↑     ↓
|  restTemplateSender defined in class path resource [org/springframework/boot/actuate/autoconfigure/tracing/zipkin/ZipkinConfigurations$RestTemplateSenderConfiguration.class]
↑     ↓
|  restTemplateBuilder defined in class path resource [org/springframework/boot/autoconfigure/web/client/RestTemplateAutoConfiguration.class]
↑     ↓
|  restTemplateBuilderConfigurer defined in class path resource [org/springframework/boot/autoconfigure/web/client/RestTemplateAutoConfiguration.class]
↑     ↓
|  metricsRestTemplateCustomizer defined in class path resource [org/springframework/boot/actuate/autoconfigure/metrics/web/client/RestTemplateObservationConfiguration.class]
└─────┘

Comment From: wilkinsona

As far as I can tell the cycle does not occur at the moment when using WebClient. It looks like this is due to WebClientMetricsConfiguration depending on MeterRegistry whereas RestTemplateObservationConfiguration depends on ObservationRegistry. This situation will change with https://github.com/spring-projects/spring-boot/issues/32518. Regardless of this, I think this is a good change to make as I think it makes sense to isolate the RestTemplate or WebClient that's used for Zipkin sending from the rest of the application's customization of them.