RFR: JDK-7184195 - java.util.logging.Logger.getGlobal().info() doesn't log without configuration (original) (raw)

Daniel Fuchs daniel.fuchs at oracle.com
Thu Jun 20 09:49:12 UTC 2013

Hi,

Here is a second revision.

<http://cr.openjdk.java.net/~dfuchs/JDK-7184195/webrev.01/>

I have added a TestGetGlobalConcurrent.java test which is somewhat similar to the other TestGetGlobal and TestGetGlobal2 tests - excepts that it creates multiple concurrent threads which will race to initialize the LogManager in different manners.

-- daniel

On 6/19/13 5:31 PM, Daniel Fuchs wrote:

Hi,

Please find below a proposed fix for: 7184195 - java.util.logging.Logger.getGlobal().info() doesn't log without configuration Jim who was the original evaluator of this bug find out that the root cause of the issue was that LogManager hadn't been initialized yet, and therefore the global Logger returned had its manager instance 'null' - and more to the point - had no configuration since the configuration is established by the LogManager. The fix proposed is simple. In getGlobal() we check whether the 'manager' variable is null - and if it is, we initialize it by calling LogManager.getLogManager(). This is a pattern which is already present at other places in the Logger.java class file. <http://cr.openjdk.java.net/~dfuchs/JDK-7184195/webrev.00/> However - initialization of LogManager has proved to be fragile in the past - in particular wrt deadlocks between Logger and LogManager caused by circular class initialization. Therefore, I have added two test files TestGetGlobal.java and TestGetGlobal2.java which try to trigger such deadlocks by calling Logger.getGlobal() or Logger.getLogger(Logger.GLOBALLOGGERNAME) before the LogManager class is initialized. The tests have a bunch of @run line trying to do so with different configurations, including by using custom LogManager subclasses, with and without a security manager on. I have seen no issue so far. best regards, -- daniel

More information about the core-libs-dev mailing list