http://bugzilla.slf4j.org/show_bug.cgi?id=176
--- Comment #30 from James R. Perkins <[email protected]> --- (In reply to comment #29) > > FWIW the fix in fixSubstitutedLoggers() method isn't really thread-safe > > either. > > As per current code flow it is thread safe. 'fixSubstitutedLoggers' is > invoked *after* the INITIALIZATION_STATE is set to > SUCCESSFUL_INITIALIZATION. So by the time it is invoked TEMP_FACTORY would > not be in use and no further SubstituteLogegrs would be created. > > So the only downside is that only during the initialization phase some log > calls would be NOOP and log output would be lost. Similar situtation occurs > in Logback if the Logback config is reset and any log message arrives during > that phase. > > If that also needs to be addressed then we can move just the SimpleLogger to > slf4j-api module and use that in place of NOOP logger for the initial > delegate in SubstituteLogger Sorry for the late reply. Yeah, sorry I missed that. That said I still don't understand why initialization just can't be thread-safe. Using SubstitueLoggers and what not just hides the issue. The bottom line is initialization of a binder is not thread-safe and I see no reason why it shouldn't be. If it's just made thread-safe there is no need for all this substitute logger code. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ slf4j-dev mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-dev
