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

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


Here is a second revision.


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

-- 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.GLOBAL_LOGGER_NAME) 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