This is a follow-up of #25. I've investigated the behaviour of the default Microsoft loggers (and some 3rd party ones) and the scopes are local not only to the logger, but also to the async context (which now of course makes sense).
I've moved the implementation from the sink to the logger and reworked it to be local to an async local, using a linked list stored in a AsyncLocal, similarly to the implementation of the LoggerExternalScopeProvider of Microsoft.Extensions.Logging
I've also renamed the property to access the scopes and reversed the list to be in the opening order as I feel it is more intuitive.
Finally, I've changed the behaviour of the obsolete LogEntry.Scope property, to return the latest active scope, as I find it hard to find a use case for the old behaviour (if really needed, in simple scenarios with a single logger can be replicate with TestSink.Scopes). Will consider adding it back later if requested.
This is a follow-up of #25. I've investigated the behaviour of the default Microsoft loggers (and some 3rd party ones) and the scopes are local not only to the logger, but also to the async context (which now of course makes sense).
I've moved the implementation from the sink to the logger and reworked it to be local to an async local, using a linked list stored in a
AsyncLocal, similarly to the implementation of the LoggerExternalScopeProvider of Microsoft.Extensions.LoggingI've also renamed the property to access the scopes and reversed the list to be in the opening order as I feel it is more intuitive.
Finally, I've changed the behaviour of the obsolete
LogEntry.Scopeproperty, to return the latest active scope, as I find it hard to find a use case for the old behaviour (if really needed, in simple scenarios with a single logger can be replicate withTestSink.Scopes). Will consider adding it back later if requested.Fixes #24
/cc @wainwrightmark