Ceki,
My goal was to avoid having to place special slf4j initialization code in my application to avoid:
-
State corruption
-
Dropped logs
-
Warnings (by SubstituteLogger or others)
related to thread-unsafe initialization. As far as I can tell, this fix resolves issue 1 but not 2 and 3.
In evaluating this fix, I don't understand:
-
When you talk about replaying dropped logs post-initialization, will the logs get replayed in order? Meaning, will the dropped calls get logged (in order) before the calls that come in after initialization?
-
Will I still get warnings at startup?
-
What is gained by having the dropped calls route to SubstituteLogger during initialization (versus blocking)?
Please help me understand what you have in mind. Thank you.
|