A general-purpose logging facility. It is modeled after
syslogd. This is a base class from which an actual
implementation is derived. It only defines how log message are written
by a client. Where the log message is written and the mechanism for
controlling logging is left up to the implementation. This class does
not define any of these mechanism and their definition is not necessary
for understand how to use this class.
Each log message is associate with a facility and has a level assigned
to it. A facility is a symbolic (String) name that defines a class of
log messages. A level is used to indicate the
It is expected that the implementation can enable, disable and
direct log messages based on these attributes. Facilities and levels
are defined symbolicly, with no restriction on the name, and form a tuple.
Several standard levels are defined as integer constants and their use
is expected to be higher performing than symbolic levels..
Normally, a single,
global instance of the object
is exists and is obtainable by a static method in this class.
Log messages are written via an object implementing LogChannel.
A channel is associated with a single facility, with the level being
specified when a message is written. Normally, a LogChannel
is obtained once at initialization time and use repeatedly. It is
permissible to obtain multiple references to the log channel for a facility,
but this is discouraged for performance reasons.
Log messages, even debugging ones, should be defined with care. They
should be terse, but clear to someone who isn't intimately familiar with
the code. Permanent debugging messages should be designed with the idea
of use when supportting a deployed product.
The central logging object needs to be configured very early in the startup
process. If logging can't be configured, then the startup should be aborted
or a object created that does some simple form of logging, such as write
to stderr. A client should never have to check if the global
logger object exists.
| 