RFR: JDK-7184195 - java.util.logging.Logger.getGlobal().info() doesn't log without configuration
mandy.chung at oracle.com
Mon Jul 1 17:51:44 UTC 2013
On 6/29/13 4:55 AM, Peter Levart wrote:
> 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  and untangling the
LogManager and Logger initialization would be possible.
> Regards, Peter
> On 06/19/2013 05:31 PM, Daniel Fuchs wrote:
>> 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.
>> 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