This Handler publishes log records to System.err.
By default the SimpleFormatter is used to generate brief summaries.

Configuration:
By default each ConsoleHandler is initialized using the following
LogManager configuration properties where <handler-name>
refers to the fully-qualified class name of the handler.
If properties are not defined
(or have invalid values) then the specified default values are used.

   <handler-name>.level
       specifies the default level for the Handler
       (defaults to Level.INFO).
   <handler-name>.filter
       specifies the name of a Filter class to use
       (defaults to no Filter).
   <handler-name>.formatter
       specifies the name of a Formatter class to use
       (defaults to java.util.logging.SimpleFormatter).
   <handler-name>.encoding
       the name of the character set encoding to use (defaults to
       the default platform encoding).


For example, the properties for ConsoleHandler would be:

   java.util.logging.ConsoleHandler.level=INFO
   java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter


For a custom handler, e.g. com.foo.MyHandler, the properties would be:

   com.foo.MyHandler.level=INFO
   com.foo.MyHandler.formatter=java.util.logging.SimpleFormatter

ErrorManager objects can be attached to Handlers to process
any error that occurs on a Handler during Logging.

When processing logging output, if a Handler encounters problems
then rather than throwing an Exception back to the issuer of
the logging call (who is unlikely to be interested) the Handler
should call its associated ErrorManager.

"/"    the local pathname separator
 "%t"   the system temporary directory
 "%h"   the value of the "user.home" system property
 "%g"   the generation number to distinguish rotated logs
 "%u"   a unique number to resolve conflicts
 "%%"   translates to a single percent sign "%"

Simple file logging Handler.

The FileHandler can either write to a specified file,
or it can write to a rotating set of files.

For a rotating set of files, as each file reaches a given size
limit, it is closed, rotated out, and a new file opened.
Successively older files are named by adding "0", "1", "2",
etc. into the base filename.

By default buffering is enabled in the IO libraries but each log
record is flushed out when it is complete.

By default the XMLFormatter class is used for formatting.

Configuration:
By default each FileHandler is initialized using the following
LogManager configuration properties where <handler-name>
refers to the fully-qualified class name of the handler.
If properties are not defined
(or have invalid values) then the specified default values are used.

   <handler-name>.level
       specifies the default level for the Handler
       (defaults to Level.ALL).
   <handler-name>.filter
       specifies the name of a Filter class to use
       (defaults to no Filter).
   <handler-name>.formatter
       specifies the name of a Formatter class to use
       (defaults to java.util.logging.XMLFormatter)
   <handler-name>.encoding
       the name of the character set encoding to use (defaults to
       the default platform encoding).
   <handler-name>.limit
       specifies an approximate maximum amount to write (in bytes)
       to any one file.  If this is zero, then there is no limit.
       (Defaults to no limit).
   <handler-name>.count
       specifies how many output files to cycle through (defaults to 1).
   <handler-name>.pattern
       specifies a pattern for generating the output file name.  See
       below for details. (Defaults to "%h/java%u.log").
   <handler-name>.append
       specifies whether the FileHandler should append onto
       any existing files (defaults to false).


For example, the properties for FileHandler would be:

   java.util.logging.FileHandler.level=INFO
   java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter


For a custom handler, e.g. com.foo.MyHandler, the properties would be:

   com.foo.MyHandler.level=INFO
   com.foo.MyHandler.formatter=java.util.logging.SimpleFormatter


A pattern consists of a string that includes the following special
components that will be replaced at runtime:

    "/"    the local pathname separator
     "%t"   the system temporary directory
     "%h"   the value of the "user.home" system property
     "%g"   the generation number to distinguish rotated logs
     "%u"   a unique number to resolve conflicts
     "%%"   translates to a single percent sign "%"

If no "%g" field has been specified and the file count is greater
than one, then the generation number will be added to the end of
the generated filename, after a dot.

Thus for example a pattern of "%t/java%g.log" with a count of 2
would typically cause log files to be written on Solaris to
/var/tmp/java0.log and /var/tmp/java1.log whereas on Windows 95 they
would be typically written to C:\TEMP\java0.log and C:\TEMP\java1.log

Generation numbers follow the sequence 0, 1, 2, etc.

Normally the "%u" unique field is set to 0.  However, if the FileHandler
tries to open the filename and finds the file is currently in use by
another process it will increment the unique number field and try
again.  This will be repeated until FileHandler finds a file name that
is  not currently in use. If there is a conflict and no "%u" field has
been specified, it will be added at the end of the filename after a dot.
(This will be after any automatically added generation number.)

Thus if three processes were all trying to log to fred%u.%g.txt then
they  might end up using fred0.0.txt, fred1.0.txt, fred2.0.txt as
the first file in their rotating sequences.

Note that the use of unique ids to avoid conflicts is only guaranteed
to work reliably when using a local disk file system.

A Filter can be used to provide fine grain control over
what is logged, beyond the control provided by log levels.

Each Logger and each Handler can have a filter associated with it.
The Logger or Handler will call the isLoggable method to check
if a given LogRecord should be published.  If isLoggable returns
false, the LogRecord will be discarded.

A Formatter provides support for formatting LogRecords.

Typically each logging Handler will have a Formatter associated
with it.  The Formatter takes a LogRecord and converts it to
a string.

Some formatters (such as the XMLFormatter) need to wrap head
and tail strings around a set of formatted records. The getHeader
and getTail methods can be used to obtain these strings.

A Handler object takes log messages from a Logger and
exports them.  It might for example, write them to a console
or write them to a file, or send them to a network logging service,
or forward them to an OS log, or whatever.

A Handler can be disabled by doing a setLevel(Level.OFF)
and can  be re-enabled by doing a setLevel with an appropriate level.

Handler classes typically use LogManager properties to set
default values for the Handler's Filter, Formatter,
and Level.  See the specific documentation for each concrete
Handler class.

The Level class defines a set of standard logging levels that
can be used to control logging output.  The logging Level objects
are ordered and are specified by ordered integers.  Enabling logging
at a given level also enables logging at all higher levels.

Clients should normally use the predefined Level constants such
as Level.SEVERE.

The levels in descending order are:

SEVERE (highest value)
WARNING
INFO
CONFIG
FINE
FINER
FINEST  (lowest value)

In addition there is a level OFF that can be used to turn
off logging, and a level ALL that can be used to enable
logging of all messages.

It is possible for third parties to define additional logging
levels by subclassing Level.  In such cases subclasses should
take care to chose unique integer level values and to ensure that
they maintain the Object uniqueness property across serialization
by defining a suitable readResolve method.

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.

A Logger object is used to log messages for a specific
system or application component.  Loggers are normally named,
using a hierarchical dot-separated namespace.  Logger names
can be arbitrary strings, but they should normally be based on
the package name or class name of the logged component, such
as java.net or javax.swing.  In addition it is possible to create
"anonymous" Loggers that are not stored in the Logger namespace.

Logger objects may be obtained by calls on one of the getLogger
factory methods.  These will either create a new Logger or
return a suitable existing Logger. It is important to note that
the Logger returned by one of the getLogger factory methods
may be garbage collected at any time if a strong reference to the
Logger is not kept.

Logging messages will be forwarded to registered Handler
objects, which can forward the messages to a variety of
destinations, including consoles, files, OS logs, etc.

Each Logger keeps track of a "parent" Logger, which is its
nearest existing ancestor in the Logger namespace.

Each Logger has a "Level" associated with it.  This reflects
a minimum Level that this logger cares about.  If a Logger's
level is set to null, then its effective level is inherited
from its parent, which may in turn obtain it recursively from its
parent, and so on up the tree.

The log level can be configured based on the properties from the
logging configuration file, as described in the description
of the LogManager class.  However it may also be dynamically changed
by calls on the Logger.setLevel method.  If a logger's level is
changed the change may also affect child loggers, since any child
logger that has null as its level will inherit its
effective level from its parent.

On each logging call the Logger initially performs a cheap
check of the request level (e.g., SEVERE or FINE) against the
effective log level of the logger.  If the request level is
lower than the log level, the logging call returns immediately.

After passing this initial (cheap) test, the Logger will allocate
a LogRecord to describe the logging message.  It will then call a
Filter (if present) to do a more detailed check on whether the
record should be published.  If that passes it will then publish
the LogRecord to its output Handlers.  By default, loggers also
publish to their parent's Handlers, recursively up the tree.

Each Logger may have a ResourceBundle associated with it.
The ResourceBundle may be specified by name, using the
getLogger(java.lang.String, java.lang.String) factory
method, or by value - using the setResourceBundle method.
This bundle will be used for localizing logging messages.
If a Logger does not have its own ResourceBundle or resource bundle
name, then it will inherit the ResourceBundle or resource bundle name
from its parent, recursively up the tree.

Most of the logger output methods take a "msg" argument.  This
msg argument may be either a raw value or a localization key.
During formatting, if the logger has (or inherits) a localization
ResourceBundle and if the ResourceBundle has a mapping for
the msg string, then the msg string is replaced by the localized value.
Otherwise the original msg string is used.  Typically, formatters use
java.text.MessageFormat style formatting to format parameters, so
for example a format string "{0} {1}" would format two parameters
as strings.

A set of methods alternatively take a "msgSupplier" instead of a "msg"
argument.  These methods take a Supplier<String> function
which is invoked to construct the desired log message only when the message
actually is to be logged based on the effective log level thus eliminating
unnecessary message construction. For example, if the developer wants to
log system health status for diagnosis, with the String-accepting version,
the code would look like:


  class DiagnosisMessages {
    static String systemHealthStatus() {
      // collect system health information
      ...
    }
  }
  ...
  logger.log(Level.FINER, DiagnosisMessages.systemHealthStatus());
With the above code, the health status is collected unnecessarily even when
the log level FINER is disabled. With the Supplier-accepting version as
below, the status will only be collected when the log level FINER is
enabled.


  logger.log(Level.FINER, DiagnosisMessages::systemHealthStatus);

When looking for a ResourceBundle, the logger will first look at
whether a bundle was specified using setResourceBundle, and then
only whether a resource bundle name was specified through the getLogger factory method.
If no ResourceBundle or no resource bundle name is found,
then it will use the nearest ResourceBundle or resource bundle
name inherited from its parent tree.
When a ResourceBundle was inherited or specified through the
setResourceBundle method, then
that ResourceBundle will be used. Otherwise if the logger only
has or inherited a resource bundle name, then that resource bundle name
will be mapped to a ResourceBundle object, using the default Locale
at the time of logging.
When mapping resource bundle names to
ResourceBundle objects, the logger will first try to use the
Thread's context class
loader to map the given resource bundle name to a ResourceBundle.
If the thread context class loader is null, it will try the
system class loader
instead.  If the ResourceBundle is still not found, it will use the
class loader of the first caller of the 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.

The management interface for the logging facility. It is recommended
to use the PlatformLoggingMXBean management
interface that implements all attributes defined in this
LoggingMXBean.  The
ManagementFactory.getPlatformMXBean method can be used to obtain
the PlatformLoggingMXBean object representing the management
interface for logging.

There is a single global instance of the LoggingMXBean.
This instance is an MXBean that
can be obtained by calling the LogManager.getLoggingMXBean()
method or from the
platform MBeanServer.

The ObjectName that uniquely identifies
the management interface for logging within the MBeanServer is:


   java.util.logging:type=Logging

The instance registered in the platform MBeanServer
is also a PlatformLoggingMXBean.

The permission which the SecurityManager will check when code
that is running with a SecurityManager calls one of the logging
control methods (such as Logger.setLevel).

Currently there is only one named LoggingPermission.  This is "control"
and it grants the ability to control the logging configuration, for
example by adding or removing Handlers, by adding or removing Filters,
or by changing logging levels.

Programmers do not normally create LoggingPermission objects directly.
Instead they are created by the security policy code based on reading
the security policy file.

There is a single global LogManager object that is used to
maintain a set of shared state about Loggers and log services.

This LogManager object:

 Manages a hierarchical namespace of Logger objects.  All
     named Loggers are stored in this namespace.
 Manages a set of logging control properties.  These are
     simple key-value pairs that can be used by Handlers and
     other logging objects to configure themselves.


The global LogManager object can be retrieved using LogManager.getLogManager().
The LogManager object is created during class initialization and
cannot subsequently be changed.

At startup the LogManager class is located using the
java.util.logging.manager system property.

The LogManager defines two optional system properties that allow control over
the initial configuration:

"java.util.logging.config.class"
"java.util.logging.config.file"

These two properties may be specified on the command line to the "java"
command, or as system property definitions passed to JNI_CreateJavaVM.

If the "java.util.logging.config.class" property is set, then the
property value is treated as a class name.  The given class will be
loaded, an object will be instantiated, and that object's constructor
is responsible for reading in the initial configuration.  (That object
may use other system properties to control its configuration.)  The
alternate configuration class can use readConfiguration(InputStream)
to define properties in the LogManager.

If "java.util.logging.config.class" property is not set,
then the "java.util.logging.config.file" system property can be used
to specify a properties file (in java.util.Properties format). The
initial logging configuration will be read from this file.

If neither of these properties is defined then the LogManager uses its
default configuration. The default configuration is typically loaded from the
properties file "lib/logging.properties" in the Java installation
directory.

The properties for loggers and Handlers will have names starting
with the dot-separated name for the handler or logger.

The global logging properties may include:

A property "handlers".  This defines a whitespace or comma separated
list of class names for handler classes to load and register as
handlers on the root Logger (the Logger named "").  Each class
name must be for a Handler class which has a default constructor.
Note that these Handlers may be created lazily, when they are
first used.

A property "<logger>.handlers". This defines a whitespace or
comma separated list of class names for handlers classes to
load and register as handlers to the specified logger. Each class
name must be for a Handler class which has a default constructor.
Note that these Handlers may be created lazily, when they are
first used.

A property "<logger>.useParentHandlers". This defines a boolean
value. By default every logger calls its parent in addition to
handling the logging message itself, this often result in messages
being handled by the root logger as well. When setting this property
to false a Handler needs to be configured for this logger otherwise
no logging messages are delivered.

A property "config".  This property is intended to allow
arbitrary configuration code to be run.  The property defines a
whitespace or comma separated list of class names.  A new instance will be
created for each named class.  The default constructor of each class
may execute arbitrary code to update the logging configuration, such as
setting logger levels, adding handlers, adding filters, etc.


Note that all classes loaded during LogManager configuration are
first searched on the system class path before any user class path.
That includes the LogManager class, any config classes, and any
handler classes.

Loggers are organized into a naming hierarchy based on their
dot separated names.  Thus "a.b.c" is a child of "a.b", but
"a.b1" and a.b2" are peers.

All properties whose names end with ".level" are assumed to define
log levels for Loggers.  Thus "foo.level" defines a log level for
the logger called "foo" and (recursively) for any of its children
in the naming hierarchy.  Log Levels are applied in the order they
are defined in the properties file.  Thus level settings for child
nodes in the tree should come after settings for their parents.
The property name ".level" can be used to set the level for the
root of the tree.

All methods on the LogManager object are multi-thread safe.

LogRecord objects are used to pass logging requests between
the logging framework and individual log Handlers.

When a LogRecord is passed into the logging framework it
logically belongs to the framework and should no longer be
used or updated by the client application.

Note that if the client application has not specified an
explicit source method name and source class name, then the
LogRecord class will infer them automatically when they are
first accessed (due to a call on getSourceMethodName or
getSourceClassName) by analyzing the call stack.  Therefore,
if a logging Handler wants to pass off a LogRecord to another
thread, or to transmit it over RMI, and if it wishes to subsequently
obtain method name or class name information it should call
one of getSourceClassName or getSourceMethodName to force
the values to be filled in.

 Serialization notes:

The LogRecord class is serializable.

 Because objects in the parameters array may not be serializable,
during serialization all objects in the parameters array are
written as the corresponding Strings (using Object.toString).

 The ResourceBundle is not transmitted as part of the serialized
form, but the resource bundle name is, and the recipient object's
readObject method will attempt to locate a suitable resource bundle.

Handler that buffers requests in a circular buffer in memory.

Normally this Handler simply stores incoming LogRecords
into its memory buffer and discards earlier records.  This buffering
is very cheap and avoids formatting costs.  On certain trigger
conditions, the MemoryHandler will push out its current buffer
contents to a target Handler, which will typically publish
them to the outside world.

There are three main models for triggering a push of the buffer:


An incoming LogRecord has a type that is greater than
a pre-defined level, the pushLevel.

An external class calls the push method explicitly.

A subclass overrides the log method and scans each incoming
LogRecord and calls push if a record matches some
desired criteria.


Configuration:
By default each MemoryHandler is initialized using the following
LogManager configuration properties where <handler-name>
refers to the fully-qualified class name of the handler.
If properties are not defined
(or have invalid values) then the specified default values are used.
If no default value is defined then a RuntimeException is thrown.

   <handler-name>.level
       specifies the level for the Handler
       (defaults to Level.ALL).
   <handler-name>.filter
       specifies the name of a Filter class to use
       (defaults to no Filter).
   <handler-name>.size
       defines the buffer size (defaults to 1000).
   <handler-name>.push
       defines the pushLevel (defaults to level.SEVERE).
   <handler-name>.target
       specifies the name of the target Handler  class.
       (no default).


For example, the properties for MemoryHandler would be:

   java.util.logging.MemoryHandler.level=INFO
   java.util.logging.MemoryHandler.formatter=java.util.logging.SimpleFormatter


For a custom handler, e.g. com.foo.MyHandler, the properties would be:

   com.foo.MyHandler.level=INFO
   com.foo.MyHandler.formatter=java.util.logging.SimpleFormatter

Print a brief summary of the LogRecord in a human readable
format.  The summary will typically be 1 or 2 lines.



Configuration:
The SimpleFormatter is initialized with the
format string
specified in the java.util.logging.SimpleFormatter.format
property to format the log messages.
This property can be defined
in the logging properties
configuration file
or as a system property.  If this property is set in both
the logging properties and system properties,
the format string specified in the system property will be used.
If this property is not defined or the given format string
is java.util.illegal,
the default format is implementation-specific.

Simple network logging Handler.

LogRecords are published to a network stream connection.  By default
the XMLFormatter class is used for formatting.

Configuration:
By default each SocketHandler is initialized using the following
LogManager configuration properties where <handler-name>
refers to the fully-qualified class name of the handler.
If properties are not defined
(or have invalid values) then the specified default values are used.

   <handler-name>.level
       specifies the default level for the Handler
       (defaults to Level.ALL).
   <handler-name>.filter
       specifies the name of a Filter class to use
       (defaults to no Filter).
   <handler-name>.formatter
       specifies the name of a Formatter class to use
       (defaults to java.util.logging.XMLFormatter).
   <handler-name>.encoding
       the name of the character set encoding to use (defaults to
       the default platform encoding).
   <handler-name>.host
       specifies the target host name to connect to (no default).
   <handler-name>.port
       specifies the target TCP port to use (no default).


For example, the properties for SocketHandler would be:

   java.util.logging.SocketHandler.level=INFO
   java.util.logging.SocketHandler.formatter=java.util.logging.SimpleFormatter


For a custom handler, e.g. com.foo.MyHandler, the properties would be:

   com.foo.MyHandler.level=INFO
   com.foo.MyHandler.formatter=java.util.logging.SimpleFormatter


The output IO stream is buffered, but is flushed after each
LogRecord is written.

Stream based logging Handler.

This is primarily intended as a base class or support class to
be used in implementing other logging Handlers.

LogRecords are published to a given java.io.OutputStream.

Configuration:
By default each StreamHandler is initialized using the following
LogManager configuration properties where <handler-name>
refers to the fully-qualified class name of the handler.
If properties are not defined
(or have invalid values) then the specified default values are used.

   <handler-name>.level
       specifies the default level for the Handler
       (defaults to Level.INFO).
   <handler-name>.filter
       specifies the name of a Filter class to use
        (defaults to no Filter).
   <handler-name>.formatter
       specifies the name of a Formatter class to use
       (defaults to java.util.logging.SimpleFormatter).
   <handler-name>.encoding
       the name of the character set encoding to use (defaults to
       the default platform encoding).


For example, the properties for StreamHandler would be:

   java.util.logging.StreamHandler.level=INFO
   java.util.logging.StreamHandler.formatter=java.util.logging.SimpleFormatter


For a custom handler, e.g. com.foo.MyHandler, the properties would be:

   com.foo.MyHandler.level=INFO
   com.foo.MyHandler.formatter=java.util.logging.SimpleFormatter

Format a LogRecord into a standard XML format.

The DTD specification is provided as Appendix A to the
Java Logging APIs specification.

The XMLFormatter can be used with arbitrary character encodings,
but it is recommended that it normally be used with UTF-8.  The
character encoding can be set on the output Handler.