Add (another) appender to this logger. Appenders are each invoked for log events as they are produced. At most, one instance of each appender will be invoked.
Send a message to this logger via its appender list.
Remove all appenders from this Logger
Is this logger enabed for the specified Level?
Is error enabled?
Append an error message
Is fatal enabled?
Append a fatal message
Return a formatted string from the given arguments
Format and emit text from the given arguments
Is info enabled?
Append an info message
Return the Level this logger is set to
Set the current level for this logger (and only this logger).
Set the current level for this logger, and (optionally) all of its descendents.
Is trace enabled?
Append a trace message
Is warn enabled?
Append a warning message
Context for a hierarchy, used for customizing behaviour of log hierarchies. You can use this to implement dynamic log-levels, based upon filtering or some other mechanism
Is this logger additive? That is, should we walk ancestors looking for more appenders?
Set the additive status of this logger. See bool additive().
Get the current formatting buffer (null if none).
Set the current formatting buffer.
Return the name of this Logger (sans the appended dot).
Get time since this application started
Is this logger enabed for the specified Level?
Append a trace message
Append an info message
Append a warning message
Append an error message
Append a fatal message
Return the name of this ILogger (sans the appended dot).
Return the Level this logger is set to
Set the current level for this logger (and only this logger).
Is this logger additive? That is, should we walk ancestors looking for more appenders?
Set the additive status of this logger. See isAdditive().
Send a message to this logger via its appender list.
Loggers are named entities, sometimes shared, sometimes specific to a particular portion of code. The names are generally hierarchical in nature, using dot notation (with '.') to separate each named section. For example, a typical name might be something like "mail.send.writer"
It is considered good form to pass a logger instance as a function or class-ctor argument, or to assign a new logger instance during static class construction. For example: if it were considered appropriate to have one logger instance per class, each might be constructed like so:
Messages passed to a Logger are assumed to be either self-contained or configured with "{}" notation a la Layout & Stdout:
Note that an internal workspace is used to format the message, which is limited to 2048 bytes. Use "{.256}" truncation notation to limit the size of individual message components. You can also use your own formatting buffer:
Or you can use explicit formatting:
To avoid overhead when constructing argument passed to formatted messages, you should check to see whether a logger is active or not:
The above will be handled implicitly by the logging system when macros are added to the language (used to be handled implicitly via lazy delegates, but usage of those turned out to be awkward).
tango.log closely follows both the API and the behaviour as documented at the official Log4J site, where you'll find a good tutorial. Those pages are hosted over <A HREF="http://logging.apache.org/log4j/docs/documentation.html">here</A>.