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

[Daniel Fuchs]

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