[ http://jira.qos.ch/browse/LBCORE-24?page=com.atlassian.jira.plugin.system.is... ] Paul Gregoire commented on LBCORE-24: ------------------------------------- Ceki, I made the change you suggested to org.slf4j.impl.StaticLoggerBinder but I cannot build logback (http://jira.qos.ch/browse/LBGENERAL-20). The change to line 93 is return (ContextSelector) cons.newInstance(new Object[]{defaultLoggerContext});

LoggerContextFilter is useless (org.slf4j.Loggerfactory bug ++) ---------------------------------------------------------------

Key: LBCORE-24 URL: http://jira.qos.ch/browse/LBCORE-24 Project: logback-core Issue Type: Bug Components: Other Affects Versions: unspecified Environment: Operating System: All Platform: All Reporter: Jens Elkner Assignee: Logback dev list

Since LoggerFactory obtains the LoggerContext to use in its static init stage, using a LoggerContextFilter as described in Chapter 8 is completely useless, since the JNDI selector is never consulted again. Digging deeper on that issue reveals, that using a ContextJNDISelector (even if it would work) rarely leads to the intended behavior (e.g. webapp related logging), and is probably not thread safe wrt. common practice and intended logging. E.g. in tomcat we have two different cases: a) each webapp provides its own slfj4*.jar as well as *logback*.jar b) slfj4*.jar as well as *logback*.jar are shared via tomcat/common/lib or tomcat/share/lib c) a und b mixed Well, to get things right, one can say case c) is unsupported ;-). In case a) logback has its own playground, so using JNDI doesn't make sense at all, since the webapp/logback has its own playground - doesn't interfere with other web apps since loaded via its dedicated classloader. However case b) is a little bit more challenging. Here the LoggerFactory and other classes are !shared! between several webapps, since loading is delegated from the dedicated webapp classloader to the shared webapp classloader, which picks up everything in share/lib , common/lib. So right now in 0.9.7, even if one uses JNDISelector a per webapp logging is impossible: The first webapp, which asks for a LoggerFactory always wins! All other webapps, which ask later for a LoggerFactory.getLogger() will get a Logger from the LoggerContext associated with the first webapp, since the context is "cached", i.e. the JNDI selector gets never consulted again. Assuming the LoggerFactory problem gets fixed by using e.g. public static Logger getLogger(* *) { return StaticLoggerBinder.SINGLETON.getLoggerFactory().getLogger(**); } there is still a problem wrt. common practice aka log* usage pattern and webapp shared classes, which can not be resolved by JNDI: Today most developer use something like: public class XY { private static [final] Logger log = LoggerFactory.getLogger(XY.class); ... } That implies the same problem, as with the current LoggerFactory bug: The class gets the Logger from the context associated with the first webapp, which needs the shared class. And that's why all other webapps, which later need this class will use the the logger context of the first webapp. So e.g. if webapp A is configured to log to /var/log/a.log and another webapp B is configured to log to /var/log/b.log the loging output of shared classes will always go to /var/log/a.log if webapp used the classes in question first, no matter on which thread aka in which webapp the shared classes are used. So even if LoggerFactory gets fixed, JNDI selector is of little use, if one wants to have a webapp dedicated log as soon as shared classes are involved. The only way to solve the didcated webapp log problem a can think of, to introduce another level of indirection in the Logger.log* etc. method, which takes care of thread local settings and the settings of its parent threads (e.g. an application may start other threads, which do not inherit the thread local settings from the current thread ...). But this would probably influence the performance of logback in a rather negative way. Another idea might be an architecture re-design: sharing Loggers would be no problem because of thread local AppenderContext soft ref, which points to an Appender in the global AppenderStore singleton ... RFE: These problems should be reflected chapter 8 of the logback manual to avoid further confusion ...

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira