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. On Thu, Aug 16, 2012 at 10:59 PM, Robert Voliva <rvoliva@gmail.com> wrote:
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:
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.
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.
-- Ceki http://tinyurl.com/proLogback
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>