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
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
