Make CELFormatterCommandParser function without a thread-singleton#44278
Closed
ravenblackx wants to merge 1 commit intoenvoyproxy:mainfrom
Closed
Make CELFormatterCommandParser function without a thread-singleton#44278ravenblackx wants to merge 1 commit intoenvoyproxy:mainfrom
ravenblackx wants to merge 1 commit intoenvoyproxy:mainfrom
Conversation
Signed-off-by: Raven Black <ravenblack@dropbox.com>
Contributor
Author
|
Ugh, never mind, the BuiltInCommandParserFactory initialization occurs before the singleton is initialized, making it a much bigger deal to refactor. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Commit Message: Make CELFormatterCommandParser function without a thread-singleton
Additional Description: Previously, initializing a
CELFormatterCommandParser(e.g. from yaml instantiating aSubstitutionFormatString) uses theServerConfigurationFactoryContextsingleton, which only works after server initialization. This means that in tests an ASSERT fails:ThreadLocalInjectableSingleton used prior to initialization. In unit tests this can be mitigated by initializing aScopedThreadLocalServerContextSetter, but this issue also occurs in the config validator used by CI. Rather than making that test also work around this issue, we can use the GenericFactoryContext that's available in this code path to initialize a reference with the required context via proper dependency injection.There's a second initialization path that doesn't have a FactoryContext available, so that one still uses the singleton, to initialize the injected reference - the path that checks configs doesn't use that path, so this solves the immediate problem.
Risk Level: Negative, it fixes an issue and changes no behavior except making for fewer touches of a singleton-instance.
Testing: Updated tests to use the modified constructor.
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a