http://bugzilla.slf4j.org/show_bug.cgi?id=291 Ceki Gulcu <listid@qos.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |listid@qos.ch --- Comment #1 from Ceki Gulcu <listid@qos.ch> 2013-03-13 12:04:20 CET --- I see the problem. By the way, it exists with the slf4j-log4j binding as well when used with log4j's own context selection mechanism. As stated in [1] Unfortunately, for non-native implementations of the SLF4J API, namely with slf4j-log4j12, log4j's repository selector will not be able to do its job properly because slf4j-log4j12, a non-native SLF4J binding, will store logger instances in a map, short-circuiting context-dependent logger retrieval. For native SLF4J implementations, such as logback-classic, repository selectors will work as expected. I reckoned that since logback-context selection is an advanced feature, users would migrate their code to slf4j (instead of log4j). Removing the cache in Log4jLoggerFactory, would solve this problem but would imply that multiple (log4j-over-slf4j) Logger instances would be created, all wrapping an slf4j loggers. I suppose this would not be such a big deal after all. [1] http://www.slf4j.org/faq.html#declared_static -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.