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

[Mandy Chung]

On 6/29/13 4:55 AM, Peter Levart wrote:
> 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?

This is a good suggestion.  Daniel has a patch to ensure both the root 
logger and global logger in the LoggerContext [1] and untangling the 
LogManager and Logger initialization would be possible.

Mandy
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018518.html
>
> 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
>