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

[Daniel Fuchs]

On 7/1/13 7:51 PM, Mandy Chung wrote:
> 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.

HI Peter, Mandy,

Well - yes - this is certainly an excellent suggestion, but I think
I'd like to do it in a separate changeset dedicated to cleanup.

The trouble here is that we would want the LogManager instance to have
a root and global logger added to it - but we would also not want
any other private LogManager instances created by the application to
have any such loggers added lazily.

We would thus need a way to know whether 'this' LogManager instance
is the default, and this can only be done by comparing to the
value of the LogManager.manager field - which could pause interesting
challenges if the said field is still null...

I'd prefer to log that as a separate issue. But this is definitely
something I want to investigate in the short term.
Would that be OK with you Peter?

best regards,

-- daniel

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