logger.log(Level.FINER, DiagnosisMessages::systemHealthStatus);
When looking for a {@code ResourceBundle}, the logger will first look at whether a bundle was specified using {@link #setResourceBundle(java.util.ResourceBundle) setResourceBundle}, and then only whether a resource bundle name was specified through the {@link #getLogger(java.lang.String,java.lang.String) getLogger} factory method.If no {@code ResourceBundle} or no resource bundle name is found,then it will use the nearest {@code ResourceBundle} or resource bundlename inherited from its parent tree.
When a {@code ResourceBundle} was inherited or specified through the{@link #setResourceBundle(java.util.ResourceBundle) setResourceBundle} method, thenthat {@code ResourceBundle} will be used. Otherwise if the logger onlyhas or inherited a resource bundle name, then that resource bundle name will be mapped to a {@code ResourceBundle} object, using the default Localeat the time of logging.
When mapping resource bundle names to {@code ResourceBundle} objects, the logger will first try to use theThread's {@linkplain java.lang.Thread#getContextClassLoader() context classloader} to map the given resource bundle name to a {@code ResourceBundle}. If the thread context class loader is {@code null}, it will try the {@linkplain java.lang.ClassLoader#getSystemClassLoader() system class loader}instead. If the {@code ResourceBundle} is still not found, it will use theclass loader of the first caller of the {@link #getLogger(java.lang.String,java.lang.String) getLogger} factory method.
Formatting (including localization) is the responsibility of the output Handler, which will typically call a Formatter.
Note that formatting need not occur synchronously. It may be delayed until a LogRecord is actually written to an external sink.
The logging methods are grouped in five main categories:
There are a set of "log" methods that take a log level, a message string, and optionally some parameters to the message string.
There are a set of "logp" methods (for "log precise") that are like the "log" methods, but also take an explicit source class name and method name.
There are a set of "logrb" method (for "log with resource bundle") that are like the "logp" method, but also take an explicit resource bundle object for use in localizing the log message.
There are convenience methods for tracing method entries (the "entering" methods), method returns (the "exiting" methods) and throwing exceptions (the "throwing" methods).
Finally, there are a set of convenience methods for use in the very simplest cases, when a developer simply wants to log a simple string at a given log level. These methods are named after the standard Level names ("severe", "warning", "info", etc.) and take a single argument, a message string.
For the methods that do not take an explicit source name and method name, the Logging framework will make a "best effort" to determine which class and method called into the logging method. However, it is important to realize that this automatically inferred information may only be approximate (or may even be quite wrong!). Virtual machines are allowed to do extensive optimizations when JITing and may entirely remove stack frames, making it impossible to reliably locate the calling class and method.
All methods on Logger are multi-thread safe.
Subclassing Information: Note that a LogManager class may provide its own implementation of named Loggers for any point in the namespace. Therefore, any subclasses of Logger (unless they are implemented in conjunction with a new LogManager class) should take care to obtain a Logger instance from the LogManager class and should delegate operations such as "isLoggable" and "log(LogRecord)" to that instance. Note that in order to intercept all logging output, subclasses need only override the log(LogRecord) method. All the other logging methods are implemented as calls on this log(LogRecord) method. @since 1.4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|