Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
ScopeContext to replace MDLC and NDLC #4124
Conversation
snakefoot
force-pushed the
snakefoot:ThreadExecutionContext
branch
from
3d8ebd5
to
e3d7a3b
snakefoot
force-pushed the
snakefoot:ThreadExecutionContext
branch
5 times, most recently
from
f163008
to
d3d5d31
snakefoot
force-pushed the
snakefoot:ThreadExecutionContext
branch
from
d3d5d31
to
48492d8
|
Kudos, SonarCloud Quality Gate passed!
|
|
After looking at NLog/NLog.Extensions.Logging#445 then I think further building blocks can be made:
But all that can come with new PullRequests. |
| /// | ||
| /// .NetCore (and .Net46) uses AsyncLocal for handling the thread execution context. Older .NetFramework uses System.Runtime.Remoting.CallContext | ||
| /// </remarks> | ||
| public static class ScopeContext |
304NotModified
Oct 6, 2020
Member
I think it's wise to move to a non-static class with an interface and a Default property. We need that for unit testing/mocking/DI In the future I also like to add GlobalContext (the same, non static and interfaces)
snakefoot
Oct 6, 2020
•
Author
Contributor
Both CallContext and AsyncLocal are static-variables, and will not disappear by living in a singleton. I was planning to let the Logger-object include the methods PushScopeProperty and PushScopeOperation, and do the mocking with Logger-object (Will also allows preconfigured-scope-properties using Layout-logic).
| /// Creates logical operation scope that includes provided properties and stack-value | ||
| /// </summary> | ||
| /// <param name="operationState">Value to added to the scope operation stack</param> | ||
| /// <param name="properties">Properties being added to the scope dictionray</param> |
snakefoot
Oct 6, 2020
Author
Contributor
Thanks. Fixed spelling. But Azure-build is now in cancelled state. Can you give it a kick? (Instead of me force-pushing)
|
Maybe I missing something, but what's the difference between property and operationProperty? |
ScopeProperty (MDLC) is name + value dictionary. Ex. "RequestId" = Guid.NewGuid(). ScopeOperationState (NDLC) is operation-description as stack. Ex.
|
… and PushOperationProperties
|
@304NotModified Anything one can do to get the ball rolling on this one. Would like to continue on with the todo-list. |
Resolves #4056
ScopeContext has some small behavior adjustments:
NdlcGetAllMessagesthat explodes when putting non-Microsoft objects into the CallContext. If adding this unit-test to master-branch then it will fail because NLog own objects are not welcome in the CallContext.ScopeContext has better performance since it performs lazy allocation of Dictionary (To ensure unique properties) until it actually has to write the log-message. And NLog PR now only uses a single AsyncLocal-variable to capture the BeginScope-state (Instead of one for NDLC and one for MDLC).
Because MDLC (and NDLC) are well-known constructs in the NLog-universe, then I prefer that
${mdlc}and${ndlc}continue to work when people using NLog.Extension.Logging upgrade to lastest NLog 5.0 (Along with IncludeMdlc on JsonLayout), Then over time people can be convinced to move to the new${scopecontext}(New PR).Very happy that all the existing unit-test for MDLC + NDLC are working without any modifications. ScopeContext is also able to handle the more exotic methods of adding / removing properties within an active scope.