Re-use entire SDK auto-config in spring starter

[zeitlinger]

#10292 is re-using the OTLP exporter logic from SDK auto-config.

There are still parts of the SDK auto-config that are not re-used currently, such as sampler

Technically, we could call the auto-config as a black box - and it would respect the spring properties.

What are the problems with this approach?

• Users cannot supply beans programmatically, because the entire object graph is created in auto-config. Example: SdkLoggerProvider
• SpiHelper uses META-INF loading (example) - wheres in Spring, users expect that @Beans are collected - we should probably load both to meet the expectations of Spring users and library authors alike.

Use Case 1: User supplies tracer provider

As a spring boot user, I want to provide my own instance of SdkTracerProvider (but let the framework configure the rest).

I'll configure the SdkTracerProvider programatically, using SdkTracerProvider.builder()....

Right now, this use case is supported with @ConditionalOnMissingBean, which instructs spring to prefer a user supplied object if available:

full code

    @Bean    
    @ConditionalOnMissingBean
    public SdkTracerProvider sdkTracerProvider(..) { .. }

The above code copies this part of the SDK auto-config code - just to add this annotation.

What can we do?

We can make the SpiHelper flexible enough that it allows

• to pass in a discovery strategy
• to pass a callback interface that checks for user supplied objects - user supplied beans in the case of spring
• maybe also a callback to register the created objects in the spring bean context (not sure if there's a use case for that)

[jeanbisutti]

@zeitlinger

There are still parts of the SDK auto-config that are not re-used currently, such as sampler

Do you have other examples in addittion to the sampler?

Users cannot supply beans programmatically, because the entire object graph is created in auto-config

Could you please elaborate? The user could define his own SdkTracerProvider bean that could replace the one provided by the starter.

[zeitlinger]

Do you have other examples in addittion to the sampler?

• resource providers: Add the Spring resource detector to the OTel Spring starter #10368
• batch processors: Make the batch log record processor of the OTel Spring starter configurable  #8963, Make the batch span processor of the OTel Spring starter configurable #8962
• log limits: https://github.com/open-telemetry/opentelemetry-java/blob/c8e1e3619e922981922a1034ce07e2a13e99d819/sdk-extensions/autoconfigure/src/main/java/io/opentelemetry/sdk/autoconfigure/LoggerProviderConfiguration.java#L116
• otel.metrics.exemplar.filter
• also span and metrics cardinality limits

[zeitlinger]

The user could define his own SdkTracerProvider

Please see Use case 1 (but we can also discuss in a meeting 😄 )