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
