-
Notifications
You must be signed in to change notification settings - Fork 5
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
A log entry produced within a scope should contain the properties defined on the scope #27
Comments
Hello! Thanks for reaching out! This behaviour is by design as the scope and the log entry are two separate concepts. As this library works at the abstraction level, that particular behaviour is not reproduced, as for example when authoring a library, you would have no knowledge of the particular logging provided used by the consumer. What do you think? Thank you, |
Ah, yes, in hindsight it makes total sense that such an aggregation lies in the purview of the logging providers. As I am using Serilog underneath I never noticed that this might not be true for all providers. For my use case I don`t particularly care if a property was added via a scope or a message, I just want to check if it is there (as Serilog will aggregate them anyway). If something like this were to be added to the library, it should probably be done on the assertion/check level. On that note: How can I find out in which scopes a particular log event participated? |
Apologies for the delay. The library is designed for Microsoft.Extensions.Logging, so it replicates the "standard" behaviour, not the particular choicies of different loggers. Let me know if that is what you are looking for and if it works for you or you would need something different, like being able to do that in lighter unit tests. You can otherwise test the scope properties, which you can retrieve from the log property (please update to 0.7.0 first has the scope support has been improved) |
When producing a log entry from within a scope, as in this sample
I expected
loggerFactory .Sink.LogEntries[0].Properties
to contain both properties, but found onlypropertiy2
. Whereasproperty0
only seems to be captured inloggerFactory.Sink.Scopes[0].Properties
. Is this intentional?This article seems to indicate that this is not the behavior of the "real" implementation.
The text was updated successfully, but these errors were encountered: