13-Jul-15 Logging

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 JUnit testing can greatly reduce this problem, but it’s impossible to see in advance all potentially useful tests Your program may go to customers (users) Typical error report from customer: “It doesn’t work.” 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, :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 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 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 );

Controlling logging levels public void Logger.setLevel(Level newLevel ) 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); Additional settings: 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 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 Logger Handler Filter Formatter applicationdestination

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: 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 It also defines two ways to format messages: SimpleFormatter (default) XMLFormatter And, of course, you can define your own Handler s and Formatter s 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 T13:21: myPackage SEVERE myClass main 10 Bad news!

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: 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 Filter s, 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