[ 
https://issues.apache.org/jira/browse/LOG4J2-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17720258#comment-17720258
 ] 

Ralph Goers commented on LOG4J2-1094:
-------------------------------------

I should have replied to [~francisco_rg], [~gaurang.parmar], and 
[~sreekanth.nair] years ago. My guess is that they are using the default 
ClassLoaderContextSelector. In a JEE environment I would expect he should be 
using the JndiContextSelector and have each application have its own 
LoggerContext and configuration. 

[~vampire] We have discussed creating a JunitLoggerContext just for this 
purpose. Without that all the tests will share the same LoggerContext, which is 
almost never what you want. If you are running the tests in parallel in a 
single test class I would expect the LoggerContextRule would suffice, assuming 
they can all share the single LoggerContext.

 

> Multi thread initialization problem
> -----------------------------------
>
>                 Key: LOG4J2-1094
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1094
>             Project: Log4j 2
>          Issue Type: Bug
>    Affects Versions: 2.3
>            Reporter: Luca Burgazzoli
>            Assignee: Ralph Goers
>            Priority: Major
>
> I wrote a very simple example which has a behaviour I do not expect:
> If I call LogManager.getLogger(..) from two threads, only one of the loggers 
> logs what I'd expect but if I add an additional call to 
> LogManager.getLogger(..) before the threads are started, I see what I'd 
> expect so it looks like there is a problem in multi threaded initialization.
> You can find the code and the configuration here:
> - 
> https://github.com/lburgazzoli/lb-chronicle/blob/master/chronicle-examples/chronicle-logger-log4j2/src/main/java/com.github.lburgazzoli.openhft.examples.chronicle.logger.log4j2/MtLogging.java
> - 
> https://github.com/lburgazzoli/lb-chronicle/blob/master/chronicle-examples/chronicle-logger-log4j2/src/main/resources/log4j2.xml
> {code}
> public class MtLogging {
>     public static void main(final String[] args) throws Exception {
>         //LogManager.getLogger("main");
>         Thread th1 = new Thread(() -> {
>             final String name = "thread-1";
>             final Logger log = LogManager.getLogger(name);
>             System.out.println("write " + name);
>             log.info("message");
>             System.out.println("done " + name);
>         });
>         Thread th2 = new Thread(() -> {
>             final String name = "thread-2";
>             final Logger log = LogManager.getLogger(name);
>             System.out.println("write " + name);
>             log.info("message");
>             System.out.println("done " + name);
>         });
>         th1.start();
>         th2.start();
>         th1.join();
>         th2.join();
>     }
> }
> {code}
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <configuration>
>     <appenders>
>         <Console name="STDOUT" target="SYSTEM_OUT">
>             <PatternLayout pattern="[TEST] [%-5p] %c - %m%n%throwable{none}"/>
>         </Console>
>     </appenders>
>     <loggers>
>         <root level="all">
>             <appender-ref ref="STDOUT"/>
>         </root>
>     </loggers>
> </configuration>
> {code}
> The code above will show:
> {noformat}
>     write thread-1
>     done thread-1 
>     write thread-2
>     [TEST] [INFO ] thread-2 - message
>     done thread-2
> {noformat}
> Any call to LogManager makes it succeed (the problem no longer occurs):
> {code}
>     LogManager.getContext(false);
>     th1.start();
>     th2.start();
>     th1.join();
>     th2.join();
> {code}
> New output:
> {noformat}
>     write thread-2
>     write thread-1
>     [TEST] [INFO ] thread-2 - message
>    done thread-2
>    [TEST] [INFO ] thread-1 - message
>    done thread-1
> {noformat}
> The funny thing is that the first thread to arrive is initialized with ERROR 
> level instead of the ALL that is given to root. In other words it seems that 
> the config has not loaded



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to