RFR: JDK-7184195 - java.util.logging.Logger.getGlobal().info() doesn't log without configuration
peter.levart at gmail.com
Sat Jun 29 11:55:42 UTC 2013
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?
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