[sdk-logs] Support builder behavior on OpenTelemetryLoggerOptions (proposal 3) #4502
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Relates to #4433
Relates to #4501
/cc @noahfalk
Changes
OpenTelemetryLoggerOptions.ConfigureOpenTelemetrymethod for configuringLoggerProviderBuilderLoggerProviderBuilder.ConfigureLoggerOptionsextension for configuringOpenTelemetryLoggerOptionsOverview
Some have already asked and I'm sure others will ask in the future: Why can't
OpenTelemetryLoggerOptionsjust be aLoggerProviderBuilder?Builders and options are fundamentally different things. Builders (typically) operate on the
IServiceCollection. Options are (typically) requested through theIServiceProvider.What this PR does is hack it to work. When
AddOpenTelemetryis called we create anOpenTelemetryLoggerOptionsinstance bound to theIServiceCollectionand invoke the configuration delegate immediately. Later on we retrieve a differentOpenTelemetryLoggerOptionsinstance once theIServiceProvideris available.Details
Today we configure logging like this:
"options" is
OpenTelemetryLoggerOptionsclass.Now the OpenTelemetry Specification has
LoggerProviderand we have aLoggerProviderBuilderAPI. The SDKLoggerProvideris fed into theILoggerintegration (OpenTelemetryLoggerProvider).There are different ways we could approach this. Today we have extensions for logging that target
OpenTelemetryLoggerOptions. We will need to targetLoggerProviderBuildernow. We could forever have two versions of every extension, but that seems lame.This PR is adding a new method
ConfigureOpenTelemetryonOpenTelemetryLoggerOptionsto try and bridge the two worlds.OpenTelemetryLoggerOptions.AddProcessorandOpenTelemetryLoggerOptions.SetResourceBuildermethods would be obsoleted as would our existing extensions onOpenTelemetryLoggerOptions.All of these styles can be interchanged.
Breaking changes
I couldn't make this work breaking changes 😭
This works today...
What will happen now is...
This is because before the delegate passed to
AddOpenTelemetryis executed on the finalOpenTelemetryLoggerOptionsinstance being built by Options API. This PR needs to make a differentOpenTelemetryLoggerOptionsinstance and invoke the callback immediately. What that means is the getters on thatOpenTelemetryLoggerOptionsreally have no idea what the state will be of the actual instance when created through Options API. They could just return lies, I decided to have them throw.Merge requirement checklist