Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-use entire SDK auto-config in spring starter #10409

Closed
zeitlinger opened this issue Feb 5, 2024 · 3 comments · Fixed by #10453
Closed

Re-use entire SDK auto-config in spring starter #10409

zeitlinger opened this issue Feb 5, 2024 · 3 comments · Fixed by #10453
Assignees
Labels

Comments

@zeitlinger
Copy link
Member

zeitlinger commented Feb 5, 2024

#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
Copy link
Member

@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
Copy link
Member Author

@zeitlinger
Copy link
Member Author

The user could define his own SdkTracerProvider

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants