[
http://jira.qos.ch/browse/LBCLASSIC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ceki Gulcu resolved LBCLASSIC-166.
----------------------------------
Fix Version/s: 0.9.19
Resolution: Fixed
Please see http://logback.qos.ch/manual/loggingSeparation.html#tamingStaticRefs
for a solution.
> 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
> Fix For: 0.9.19
>
>
> 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
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
