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

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.



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