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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user> >> > >
_______________________________________________ Logback-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/logback-user
