{@code LogManager} is used to maintain configuration properties of the
logging framework, and to manage a hierarchical namespace of all named
{@code Logger} objects.
There is only one global {@code LogManager} instance in the
application, which can be get by calling static method
{@link #getLogManager()}. This instance is created and
initialized during class initialization and cannot be changed.
The {@code LogManager} class can be specified by
java.util.logging.manager system property, if the property is unavailable or
invalid, the default class {@link java.util.logging.LogManager} will
be used.
When initialization, {@code LogManager} read its configuration from a
properties file, which by default is the "lib/logging.properties" in the JRE
directory.
However, two optional system properties can be used to customize the initial
configuration process of {@code LogManager}.
- "java.util.logging.config.class"
- "java.util.logging.config.file"
These two properties can be set in three ways, by the Preferences API, by the
"java" command line property definitions, or by system property definitions
passed to JNI_CreateJavaVM.
The "java.util.logging.config.class" should specifies a class name. If it is
set, this given class will be loaded and instantiated during
{@code LogManager} initialization, so that this object's default
constructor can read the initial configuration and define properties for
{@code LogManager}.
If "java.util.logging.config.class" property is not set, or it is invalid, or
some exception is thrown during the instantiation, then the
"java.util.logging.config.file" system property can be used to specify a
properties file. The {@code LogManager} will read initial
configuration from this file.
If neither of these properties is defined, or some exception is thrown
during these two properties using, the {@code LogManager} will read
its initial configuration from default properties file, as described above.
The global logging properties may include:
- "handlers". This property's values should be a list of class names for
handler classes separated by whitespace, these classes must be subclasses of
{@code Handler} and each must have a default constructor, these
classes will be loaded, instantiated and registered as handlers on the root
{@code Logger} (the {@code Logger} named ""). These
{@code Handler}s maybe initialized lazily.
- "config". The property defines a list of class names separated by
whitespace. Each class must have a default constructor, in which it can
update the logging configuration, such as levels, handlers, or filters for
some logger, etc. These classes will be loaded and instantiated during
{@code LogManager} configuration
This class, together with any handler and configuration classes associated
with it, must be loaded from the system classpath when
{@code LogManager} configuration occurs.
Besides global properties, the properties for loggers and Handlers can be
specified in the property files. The names of these properties will start
with the complete dot separated names for the handlers or loggers.
In the {@code LogManager}'s hierarchical namespace,
{@code Loggers} are organized based on their dot separated names. For
example, "x.y.z" is child of "x.y".
Levels for {@code Loggers} can be defined by properties whose name end
with ".level". Thus "alogger.level" defines a level for the logger named as
"alogger" and for all its children in the naming hierarchy. Log levels
properties are read and applied in the same order as they are specified in
the property file. The root logger's level can be defined by the property
named as ".level".
All methods on this type can be taken as being thread safe.
|