With these changes an OTLP HTTP/protobuf exporter is auto-configured if opentelemetry-exporter-otlp is on the classpath.

Closes gh-34390

Comment From: jonatan-ivanov

I put this back to draft since support for (auth) headers should be also added.

Comment From: AndersClausen

@jonatan-ivanov Really looking forward to this feature being made available, as it is really the last thing that is preventing us from migrating to Spring Boot 3.x. Can you tell me which release you're aiming for? Cheers

Comment From: jonatan-ivanov

@AndersClausen See Andy setting the milestone on this PR (formerly, the connected issue had the same milestone). If you want to, you can migrate and try this out, with the latest 3.x, you "just" need to create beans, see what this PR does. It's not optimal and should be temporary but it should be simple and lets you try things out.

Comment From: chicobento

Hi @jonatan-ivanov , we are facing some issues integrating this into our project. The scenario is the following:

  • we have a custom class that implements SpanExporter interface and internally wraps our own mutable OtlpHttpSpanExporter
  • with this, we need to prevent the OtlpAutoConfiguration from creating the OtlpHttpSpanExporter Bean. However, the @ConditionalOnMissingBean is based only on OtlpHttpSpanExporter and OtlpGrpcSpanExporter beans, which is not our case as we implement SpanExporter interface and cannnot descend from the OtlpHttpSpanExportersince its final

Some possible solutions to my problem that I tried: - Remove OtlpAutoConfiguration: this behavior is added by a internal library, so I cannot easily remove the OtlpAutoConfiguration without impacting the applications that uses our lib - Replace the SpanProcessor: as the OpenTelemetryAutoConfiguration.otelSpanProcessor method does not have a @ConditionalOnMissingBean. I cannot easily replace the SpanProcessor with a custom one that would ignore the OtlpHttpSpanExporter Bean provided by OtlpAutoConfiguration - Replace the OpenTelemetryAutoConfiguration.otelSdkTracerProvider: this would not work because the SpanProcessor.otelSpanProcessor will always instantiate a BatchSpanProcessor and start its thread. I'd have to shutdown it

Do you have any other suggestion on how can I overcome this ?

I was wondering if isn't the current OtlpAutoConfiguration.otlpHttpSpanExporter factory method too intrusive as it always provide a SpanExporter Bean even when the application has already defined its own SpanExporter ? Can we change this to a simple @ConditionalOnMissingBean(SpanExporter.class) ?

Comment From: jonatan-ivanov

@chicobento I created a separate issue to discuss this, could you please check my answer there and reply to my questions? https://github.com/spring-projects/spring-boot/issues/35596