Hi,
Please find below a changeset that will fix
8023168: Cleanup LogManager class initialization and
LogManager/LoggerContext relationship.
<http://cr.openjdk.java.net/~dfuchs/webrev_8023168/webrev.00/>
LogManager class initialization is fragile: because Logger
constructor calls LogManager.getLogManager, and because
LogManager calls new Logger during LogManager class initialization,
and because the global logger is instantiated during Logger class
initialization, loading Logger.class or LogManager.class can lead to
challenging hard to diagnose issues.
This fix untangles the class initialization of Logger and
LogManager, and also cleans up the relationship between LogManager,
LoggerContext, and Logger. This should address Peter Levart's comment in
<http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018544.html>
<<
Why is it necessary to add root and global loggers to
LogManager in it's static initializer? Global Logger could be created
and initialized lazily, when 1st requested (in static initialization
of Logger class), and the root Logger is always "ensured" lazily
before any other Logger is initialized. If the dependency on Logger
class was removed from LogManager static initialization, then Logger
static/lazy initialization could depend on LogManager (either just
LogManager.manager field when fully configured LogManager is not
needed/can't be requested or LogManager.getLogManager() for fully
configured LogManager) ...
The initialization of LogManager, root & default Loggers is very
entangled currently and any change to such code can be fragile.
>>
Note that a consequence of this cleanup is that two intermittent
test failures caused by race conditions / bad isolation will
also get fixed:
JDK-8019945 test/java/util/logging/LogManagerInstanceTest.java
failing intermittently
JDK-8021003
java/util/logging/Logger/getGlobal/TestGetGlobalConcurrent.java
fails intermmittently
best regards,
-- daniel
