[ http://jira.qos.ch/browse/LBCLASSIC-166?page=com.atlassian.jira.plugin.syste... ] Gabriele Contini commented on LBCLASSIC-166: -------------------------------------------- A statement is not clear i try to rephrase it: I want the logs of Hibernate generated by app1 are separated from the logs of hibernate generated by app2, and i want to enable debug logs for app1 from logback-app1.xml leaving unchanged the logs produced by app2. | \/ I want the logs written by hibernate for app1 persistence calls are separated from the logs of hibernate generated for app2 persistence calls, and i want to be able to tune hibernate logs for calls generated by app1 from logback-app1.xml leaving unchanged the logs produced by app2.
Static logger references in shared classes doesn't work with JNDIContextSelector --------------------------------------------------------------------------------
Key: LBCLASSIC-166 URL: http://jira.qos.ch/browse/LBCLASSIC-166 Project: logback-classic Issue Type: New Feature Components: Other Affects Versions: 0.917 Reporter: Gabriele Contini Assignee: Logback dev list
The issue was already described in: LBCLASSIC-87 by Lars Ködderitzsch {quote} As Jens already pointed out the most common pattern to logging (even in common libaries as Jakarta Commons, Spring whatsoever) is using a static logger, eg. public class XY { private static [final] Logger log = LoggerFactory.getLogger(XY.class); ... } If such libraries are shared (either by being in tomcats shared libs, or by being directly in the ear) by multiple webapps, the logger context wins in which the original loading of the logging class (aka XY, see above) happens. To make an example. An ear contains two webapplications A and B, both have different logger context CtxA and CtxB. A library (say Spring for instance) is place in the ear and both webapps reference the library through their MANIFEST.MF. On application startup webapp A gets initialized first, during initialisation the classes of the shared libary (Spring) are loaded, therefor static loggers initialized with the context CtxA. Now webapp B gets initialized, classes of the shared libary are already loaded by the EARClassloader, the loggers continue to use CtxA. At runtime regardless of wich logger context will be set by context selectors of the webapps, all logging done by the shared classes will always go to CtxA. One can argue that common libaries should not use static loggers, but always obtain loggers freshly from the LoggerFactory. But that is a pipe dream, because the de-facto pattern in obtaining and using a logger is through a static field as depicted above. To achieve true per-webapp logging, already initialized loggers need to be able to switch logger contexts, for instance through TreadLocal or other mechanisms. {quote} And was closed with: {quote} If you need static references problem to be dealt with, then please file a *new* jira issue. {quote} I want to separate hibernate logs in my j2ee application (under jboss). Hibernate is included in server libs, and it uses static loggers: {code} public class XY { private static [final] Logger log = LoggerFactory.getLogger(XY.class); ... } {code} I also want to use separate configuration files for each j2ee application (so sifting appender is not enough), thus i'm using the JndiContextSelector. Logback is unable to switch context once hibernate is initialized, and the logger separation doesn't work for static loggers in shared libraries. --- I also tried to do my own ContextSelector in order to have a Logger that perform a jndi lookup when it's needed but: * ''LoggerContext'' has a method ''getLogger(String)'' that is final. I can't override LoggerContext and return my own instance of Logger. * In my opinion the ''contextSelector.getLoggerContext()'' could return a ''ILoggerFactory'' (there is no need it returns a full ''LoggerContext'' Best regards. Gabriele Contini
-- 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