1. Introduction to Logging
This most basic form of logging involves developers manually inserting
code into their applications to display small (or large) pieces of internal
state information to help understand what's going on. It's a useful technique
that every developer has used at least once. The problem is that it doesn't
scale. Using print statements for a small program is fine, but for a large,
commercial grade piece of software there is far too much labor involved
in manually adding and removing logging statements.
C programmers know, of course, that the way to conditionally add and
remove code is via the C preprocessor and the #ifdef
directive. Unfortunately, Java doesn't have a preprocessor. How can we
make logging scale to a useful level in Java?
A simple way to provide logging in your program is to use the Java
compiler's ability to evaluate boolean expressions at compile time, provided
that all the arguments are known. For example, in this code, the println
statements will not be executed if DEBUG not set to true.
class foo {
public
bar() {
if(DEBUG) {
System.out.println("Debugging enabled.");
}
}
}
A much better way, and the way that most logging is done in environments
where the logged output is important, is to use a logging class. A much
better way, and the way that most logging is done in environments where
the logged output is important, is to use a logging class.
A logging class collects all the messages in one central place and
not only records them, but can also sort and filter them so that you don't
have to see every message being generated. A logging class provides
more information than just the message. It can automatically add information
such as the time the event occurred, the thread that generated the message,
and a stack trace of where the message was generated.
Some logging classes will write their output directly to the screen
or a file. More advanced logging systems may instead open a socket to allow
the log messages to be sent to a separate process, which is in turn responsible
for passing those messages to the user or storing them. The advantage with
this system is that it allows for messages from multiple sources
to be aggregated in a single location and it allows for monitoring remote
systems.
The format of the log being generated should be customizable. This
could start from just allowing setting the Log "level" - which means that
each log message is assigned a severity level and only messages of greater
importance than the log level are logged - to allowing more flexible log
file formatting by using some sort LogFormatter objects that do transformations
on the logging information.
The logging service should be able to route logging information to
different locations based on the type of the information. Examples might
be printing certain messages to the console, writing to a flat file, to
a number of different flat files, to a database and so on. Examples of
different types information could be for example errors, access information
etc.
Features
An appropriate logging library should provide these features
-
Control over which logging statements are enabled or disabled,
-
Define importance or severity for logging statement via a set of levels
-
Manage output destinations,
-
Manage output format.
-
Manage internationalization (i18n)
and Localization (L10N)
-
Offer a way to configure above features.
Relevant Logging Framework
According to features a logging framework should provide, several
logging API and tools have been provided, the most popular are:
Main Next