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

Mandy Chung mandy.chung at oracle.com
Tue Oct 30 00:18:25 UTC 2012


What I mean is when multiple threads are using j.u.logging and one calls 
Logger.getGlobal() but the LogManager class initialization is calling 
Logger.getGlobal(), what will happen?   similar to what the 
LoggingDeadlock.java test does [1].  This is the code in LogManager I'm 
referring to.

       // Adding the global Logger. Doing so in the Logger.<clinit>
       // would deadlock with the LogManager.<clinit>.
       Logger.getGlobal().setLogManager(manager);
       manager.addLogger(Logger.getGlobal());


Also, the logging initialization is fragile.  I would suggest to verify 
if logging using the global logger by multiple threads print all log 
messages correctly.

There are several test/java/util/logging/LoggingDeadlock* tests that you 
should check out if they adequately verify your fix.

Mandy

[1] 
http://hg.openjdk.java.net/jdk8/tl/jdk/file/00cd9dc3c2b5/test/java/util/logging/LoggingDeadlock.java

On 10/29/2012 3:30 PM, Jim Gish wrote:
> Hi Mandy,
>
> I don't understand your second sentence.  Could you please clarify?
>
>
> Thanks,
>     Jim
>
> On 10/29/2012 06:05 PM, Mandy Chung wrote:
>> Jim,
>>
>> The logging deadlock issue is subtle and complex.  Do we have a test 
>> case that verifies your fix that is  deadlock-free?
>>
>> I can't tell for sure but looks like it smells the potential deadlock 
>> if Logger.getGlobal() triggers the LogManager class initialization 
>> but LogManager.<clinit> calls Logger.getLogger().setLogManager().
>>
>> Maybe you already see this - 4994705 may give you some idea of the 
>> deadlock problem.
>>
>> Hope this helps.
>> Mandy
>>
>> On 10/24/2012 4:13 PM, Jim Gish wrote:
>>> Please review
>>> http://cr.openjdk.java.net/~jgish/Bug7184195-global-logger-init-fix/
>>>
>>> In JDK7, Logger.global was deprecated because of potential deadlock 
>>> problems.  The method getGlobal() was introduced as a convenience 
>>> method to get the global logger in lieu of this or calling 
>>> Logger.getLogger(Logger.GLOBAL_LOGGER_NAME). Unfortunately, this was 
>>> broken out of the gate.  getGlobal() simply used the deprecated 
>>> static variable global, but this had the result of returning the 
>>> global logger without initializing the logging system.  As a result, 
>>> simply calling Logger.getGlobal().INFO("msg") does nothing.  So much 
>>> for the convenience of a simple global logger for devs to use ootb 
>>> without any setup required.
>>>
>>> This simple fix simply returns 
>>> Logger.getLogger(Logger.GLOBAL_LOGGER_NAME) when getGlobal() is 
>>> called and hence results in proper setup of the logging sytem /and 
>>> /a working global logger  with no "assembly" required :-)
>>>
>>> Thanks,
>>>    Jim
>>>
>



More information about the core-libs-dev mailing list