[
https://issues.apache.org/jira/browse/LOG4J2-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14698203#comment-14698203
]
Bart S. commented on LOG4J2-1094:
---------------------------------
I think expecting a subsystem to configure itself automatically is weird
anyway. I would personally always want to provide a main access path; and hence
a single configuration method used by that access path. The reason this is not
so is probably for subsystems (such as libraries) who are not capable of doing
such a thing (the main program should handle it) and hence to ensure their
operation, the system automatically configures itself without intervention by
the 'user'. Any subsystem should not *have* to initialize the logging subsystem
because the 'chain of dependencies' does not work like that. It could sign in
to a interface component (like sfl4j) that the main program configures to work
with whatever package is used (e.g. log4j) (in essence it configures itself,
but I would not want that) and then the main program sets up the logging
environment, and through the bridge any library can use it and all is well. At
least that's how I'd want it.
At this point LogManager kinds performs that function. But it is either with
getContext, or with setFactory, or with getLogger, there is not really a
defined way to initialize which is a bit troublesome to me. Now to prevent the
thread problems in this Jira you have to make any call, even though you can't
use the result, they are really unnecessary calls that have a side effect
(static initialization) that you need. That's what you get ..... when you
design it like this. On the other hand you could call getLogger() in the
constructor to the thread, but that's also a way of avoiding the problem. Why
does my program not encounter the problem? Mostly, solely, because my [main]
thread also does logging right at the start when there is only one thread. That
is not a deterministic outcome, that is just luck, so to speak. Perhaps it is
because it calls setFactory - also not really something that should completely
initialize the system. So my not encountering any of this problem is just a
lucky side affect of how the program is constructed. In fact I programmatically
(yeah, again...) setup everything so a natural side effect is the
initialization taking place.
I just consider myself lucky ;-).
Regards...
> 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
>
> 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 fine 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
> 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:
> {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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
