Logging
26-Jul-16
What is logging?

“Logging” is producing messages that tell you what
your program is doing




It’s not much different than using System.out.println(...)
Log messages can go to the console, to a file, or one of
several other places (e.g. sent over the Internet)
You can use logging to help you debug a program
You can use logging to produce a file when the user
runs your program
Why use logging?

Reality: Large programs always have bugs



Your program may go to customers (users)
Typical error report from customer: “It doesn’t work.”



JUnit testing can greatly reduce this problem, but it’s
impossible to see in advance all potentially useful tests
We love it when we have a customer who tries assorted things
and gives us a detailed scenario in which the program fails
Such customers are rare
Here’s what you want to tell the typical customer:

“Send us the log; it’s in such-and-such a place.”
Basic use




import java.util.logging.*;
private static Logger myLogger =
Logger.getLogger("myPackage");
myLogger.log(Level.SEVERE, "Bad news!");
Aug 15, 2004 10:51:09 AM myPackage.Sync main
SEVERE: Bad news!
Logging levels and methods









Level.SEVERE
Level.WARNING
Level.INFO
Level.CONFIG
Level.FINE
Level.FINER
Level.FINEST







myLogger.severe(String msg);
myLogger.warning(String msg);
myLogger.info(String msg);
myLogger.config(String msg);
myLogger.fine(String msg);
myLogger.finer(String msg);
myLogger.finest(String msg);
These levels are ordered, so that you can set the level of
severity that results in log messages
However, the levels have no inherent meaning--they are
what you make of them
Controlling logging levels

public void Logger.setLevel(Level newLevel)




Additional settings:



Sets the logger to log all messages at newLevel or above
Logger calls at lower levels don’t do anything
Example: logger.setLevel(Level.WARNING);
logger.setLevel(Level.ALL);
logger.setLevel(Level.OFF);
public Level getLevel()


Note that this returns a Level, not an int
Level has intValue() and toString() methods
Additional Logger methods






void entering(String sourceClass, String sourceMethod)
void entering(String sourceClass, String sourceMethod,
Object param1)
void entering(String sourceClass, String sourceMethod,
Object[] params)
void exiting(String sourceClass, String sourceMethod)
void exiting(String sourceClass, String sourceMethod,
Object result)
These log messages at level FINER
Logging flow of control
application
Logger
Filter






Handler
Filter
destination
Formatter
You send your message to a Logger
The Logger checks a Filter to see whether to ignore the message
The Logger sends the message to a Handler to put the message
somewhere
The Handler checks another Filter to see whether to ignore this
kind of message sent to this destination
The Handler calls a Formatter to decide what kind of a text
string to produce
The Handler sends the formatted message somewhere
Filters



Filter is an interface; it defines the single method
boolean isLoggable(LogRecord record)
A LogRecord is another class in java.util.logging;
it provides numerous methods for examining the
proposed logging message
We won’t go into the details of LogRecord in this
lecture (see the API if you need to use this)
Logging formatting and destinations

The JDK defines five Handlers:






It also defines two ways to format messages:




StreamHandler: sends messages to an OutputStream
ConsoleHandler: sends messages to System.err (default)
FileHandler: sends messages to a file
SocketHandler: sends messages to a TCP port
MemoryHandler: buffers messages in memory
SimpleFormatter (default)
XMLFormatter
And, of course, you can define your own Handlers and Formatters
As you can tell from the “Basic Use” slide earlier, you can
ignore all of this and just use the defaults
Using a FileHandler


try {
logger.addHandler(new FileHandler("myLogFile"));
}
catch (SecurityException e) {
e.printStackTrace();
}
The default Formatter for a FileHandler is
XMLFormatter
FileHandler results
<?xml version="1.0" encoding="MacRoman" standalone="no"?>
<!DOCTYPE log SYSTEM "logger.dtd">
<log>
<record>
<date>2004-08-15T13:21:26</date>
<millis>1092590486248</millis>
<sequence>0</sequence>
<logger>myPackage</logger>
<level>SEVERE</level>
<class>myClass</class>
<method>main</method>
<thread>10</thread>
<message>Bad news!</message>
</record>
</log>
Reading log files


Don’t like XML? See the SimpleFormatter class
When you log, your log messages must be
exceptionally easy to understand


Remember, you might see a log file months or even years
after you wrote the program
Messages such as at1: 12 37 5 may no longer make any
sense to you
What to log

Here’s what you don’t want to log:



Everything!
Specific methods only after an error has occurred
Here’s what you do want to log:




“Critical events,” such as updating a database
Results of a long sequence of operations
Interactions with other components of a large system
Actions known to be complex or error-prone
When logging goes bad

Here’s an all-too-common error:



Create log files on every run of the program
Never get rid of old log files
Solution:

Use the FileHandler class


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.
The rest of the story



As usual, I’ve only given you a few features beyond
the most basic usage
If you want to know about Filters, other destinations
than the console or a file, etc., it’s all in the Java API
You should also know that there is an alternative open
source logging package, log4j



log4j has been around longer than Sun’s logging package
Many people feel that log4j is better
I didn’t cover it because it isn’t installed in the labs here
The End