[logback-dev] [JIRA] Commented: (LBCLASSIC-166) Static logger references in shared classes doesn't work with JNDIContextSelector

[Ceki Gulcu (JIRA)]

    [ http://jira.qos.ch/browse/LBCLASSIC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11351#action_11351 ] 

Ceki Gulcu commented on LBCLASSIC-166:
--------------------------------------

Hello Gabriele,

Here is my understanding of your use case. Let E be an EAR containing web-app W1 and web-app W2. Let class loader CL_E be the class loader for E and CL_W1, CL_W2 be the class loader for W1 and respectively W2. CL_E is the parent of both CL_W1 and CL_W2. Before going further, is the above analysis correct? 


> 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