To follow up on this, I was able to fix our problem. I basically re-implemented jcl-over-slf4j with a LogFactory implementation almost identical to logback's LoggerFactory - which uses the ContextSelector code. Replaced that implementation instead of jcl-over-slf4j and it worked.
Thanks for pointing me in that direction. I can see now that the jcl-over-slf4j LogFactory doesn't use the logging context selectors.Ceki - is there a path forward from here for us? Or are we just stuck with this behavior? Could the jcl-over-slf4j LogFactory conceivably be changed to use context selectors? Any other ideas/alternatives?
On Thu, Aug 16, 2012 at 4:04 PM, ceki <ceki@qos.ch> wrote:On 16.08.2012 22:44, Robert Voliva wrote:Both jcl-over-slf4j and log4j-over-slf4j cache the loggers they create. It follows that context selections does not work in the same way as they do for native slf4j, i.e. logback, loggers.
Chris - by any chance are the messages that are ending up in the wrong
context's log coming from commons-logging API loggers? I seem to have
narrowed down my issue to just statements logged through
the jcl-over-slf4j dependency. It seems like straight slf4j Logger
statements are logging to the correct log files.
--
Ceki
http://tinyurl.com/proLogback
_______________________________________________
Logback-user mailing list
Logback-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-user