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

Peter Levart peter.levart at gmail.com
Mon Jul 1 19:15:27 UTC 2013

On 07/01/2013 08:07 PM, Daniel Fuchs wrote:
> 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?

Of course.

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

More information about the core-libs-dev mailing list