http://bugzilla.slf4j.org/show_bug.cgi?id=176 --- Comment #8 from Ceki Gulcu <listid@qos.ch> 2011-07-06 16:07:42 CEST --- Timofey, you are right to say that the problem arises when several threads call to LoggerFactory.getLogger. However, there is "some" dependence on actual StaticLoggerBinder implementation because initial configuration occurs within that first call. This is true for all backends performing auto-configuration on first use, e.g. log4j, logback and j.u.l. If auto-configuration were delegated to a different thread then SLF4J binding phase would take less time. This would in turn reduce the probability of creating tempLoggers. However, there is still no guarantee that no tempLoggers would be created. In fact delegating auto-configuration to a different thread might have little or no impact on the creating of tempLoggers, especially if the delegation process is itself comparatively long. At this time, I am just trying to understand the implications of different solutions. Addressing this problem in logback would help to keep SLF4J as dumb as possible but no dumber. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.