-
Bug
-
Resolution: Unresolved
-
P4
-
None
-
21
-
None
When the j.u.l framework is loaded, a configuration file is parsed and bootstrap Loggers are redirected to the j.u.l Logger equivalent:
try {
readConfiguration();
// Platform loggers begin to delegate to java.util.logging.Logger
jdk.internal.logger.BootstrapLogger.redirectTemporaryLoggers();
} catch (Exception ex) {
assert false : "Exception raised while reading logging configuration: " + ex;
}
If an issue occurs in above operation, an Exception is caught and ignored unless assert mode is on. This can be a tricky issue to debug for end users. Take for example a missing logger configuration file (conf/logging.properties). An IOException is thrown, the LogManager continues but Bootstrap Loggers never get promoted to j.u.l Loggers.
It's probably reasonable to allow the JDK to continue execution but perhaps we can indicate an issue to end user. Printing the issue to stderr might be acceptable for such scenarios (which should be very rare)
try {
readConfiguration();
// Platform loggers begin to delegate to java.util.logging.Logger
jdk.internal.logger.BootstrapLogger.redirectTemporaryLoggers();
} catch (Exception ex) {
assert false : "Exception raised while reading logging configuration: " + ex;
}
If an issue occurs in above operation, an Exception is caught and ignored unless assert mode is on. This can be a tricky issue to debug for end users. Take for example a missing logger configuration file (conf/logging.properties). An IOException is thrown, the LogManager continues but Bootstrap Loggers never get promoted to j.u.l Loggers.
It's probably reasonable to allow the JDK to continue execution but perhaps we can indicate an issue to end user. Printing the issue to stderr might be acceptable for such scenarios (which should be very rare)