Construct a LoggerInstance with the specified name for the given hierarchy. By default, logger instances are additive and are set to emit all events.
Emit a textual log message from the given string
Add (another) appender to this logger.
Is this logger additive configured as additive ?
Set the additive status of this logger. See bool additive().
Emit a textual log message from the given string
Set the current formatting buffer.
Remove all appenders from this Logger
Toggles the stats collecting for this logger and optionally for all its descendants.
Is this logger enabled for the specified Level?
Append a message with a severity of Level.Error.
Append a message with a severity of Level.Fatal.
Format and emit a textual log message from the given arguments
Append a message with a severity of Level.Info.
See if the provided Logger name is a parent of this one.
See if the provided Logger is a better match as a parent of this one.
Set the current level for this logger (and only this logger).
Set the current level for this logger, and (optionally) all of its descendants.
Append a message with a severity of Level.Trace.
Append a message with a severity of Level.Warn.
Indicator if the log emits should be counted towards global stats.
Level at which this Logger is configured
Next logger in the list, maintained by Hierarchy
Parent of this logger (maintained by Hierarchy)
Defines the level at which a message can be logged
Return the enum value associated with name, or a default value
Return the name associated with level
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
Set the current Level for this logger (and only this logger).
Set the additive status of this logger
Send a message to this logger.
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 ocean.text.convert.Formatter:
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:
If argument construction has some overhead which you'd like to avoid, you can check to see whether a logger is active or not:
The ocean.util.log package 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: http://logging.apache.org/log4j/docs/documentation.html