[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.ConfigureOpenTelemetry
method for configuringLoggerProviderBuilder
LoggerProviderBuilder.ConfigureLoggerOptions
extension for configuringOpenTelemetryLoggerOptions
Overview
Some have already asked and I'm sure others will ask in the future: Why can't
OpenTelemetryLoggerOptions
just 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
AddOpenTelemetry
is called we create anOpenTelemetryLoggerOptions
instance bound to theIServiceCollection
and invoke the configuration delegate immediately. Later on we retrieve a differentOpenTelemetryLoggerOptions
instance once theIServiceProvider
is available.Details
Today we configure logging like this:
"options" is
OpenTelemetryLoggerOptions
class.Now the OpenTelemetry Specification has
LoggerProvider
and we have aLoggerProviderBuilder
API. The SDKLoggerProvider
is fed into theILogger
integration (OpenTelemetryLoggerProvider
).There are different ways we could approach this. Today we have extensions for logging that target
OpenTelemetryLoggerOptions
. We will need to targetLoggerProviderBuilder
now. We could forever have two versions of every extension, but that seems lame.This PR is adding a new method
ConfigureOpenTelemetry
onOpenTelemetryLoggerOptions
to try and bridge the two worlds.OpenTelemetryLoggerOptions.AddProcessor
andOpenTelemetryLoggerOptions.SetResourceBuilder
methods 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
AddOpenTelemetry
is executed on the finalOpenTelemetryLoggerOptions
instance being built by Options API. This PR needs to make a differentOpenTelemetryLoggerOptions
instance and invoke the callback immediately. What that means is the getters on thatOpenTelemetryLoggerOptions
really 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