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

[Peter Levart]

Hi,

I haven't studied this deeply yet, but maybe somebody knows the answer: 
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.

What dou you think of untangling it?

Regards, Peter

On 06/19/2013 05: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