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

[Peter Levart]

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