-
Enhancement
-
Resolution: Cannot Reproduce
-
P5
-
None
-
6
-
x86
-
windows_2000
FULL PRODUCT VERSION :
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
JDK 6.0
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 [Version 5.00.2195]
A DESCRIPTION OF THE PROBLEM :
1. All convenience logging methods in Logger.java should NOT be testing
the logging level (because *log( LogRecord )* will do that anyway).
2. All checks of the logging level in Logger.java should call getLevel()
rather than reference the internal variable, so that subclassing
getLevel() is effective.
Barring the above changes, at least properly DOCUMENT what is actually
happening.
I have worked around this problem by subclassing a Handler and Formatter
instead, and making my Level checks there. In fact, after examining the
logging package code, those are superior places to be making such checks
anyway, due to the architecture of the logging package (the fact that
logger output may be duplicated to multiple streams). Your logging
tutorial and documentation should probably emphasize that.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
When subclassing Logger.log(LogRecord record), also sublcass the config and fine methods.
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
JDK 6.0
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 [Version 5.00.2195]
A DESCRIPTION OF THE PROBLEM :
1. All convenience logging methods in Logger.java should NOT be testing
the logging level (because *log( LogRecord )* will do that anyway).
2. All checks of the logging level in Logger.java should call getLevel()
rather than reference the internal variable, so that subclassing
getLevel() is effective.
Barring the above changes, at least properly DOCUMENT what is actually
happening.
I have worked around this problem by subclassing a Handler and Formatter
instead, and making my Level checks there. In fact, after examining the
logging package code, those are superior places to be making such checks
anyway, due to the architecture of the logging package (the fact that
logger output may be duplicated to multiple streams). Your logging
tutorial and documentation should probably emphasize that.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
When subclassing Logger.log(LogRecord record), also sublcass the config and fine methods.