Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Write custom appenders for log4j

Extend log4j to support lightweight over-the-network logging

By Allen Holub, JavaWorld.com, 12/20/04

 if( debug )
    System.out.println("Debugging diagnostic");

Logging has several advantages over simple println() statements, however. The logging system can add contextual information—filename, line number, and date, for example—to the message automatically. You can redirect the messages to different destinations, or change the formatting, without recompiling your program. (In log4j, you just modify a simple properties file.) You can easily turn categories of messages on and off so you can see debug messages when you're debugging, but easily turn them off when you're not, for example.

Logging is central to all of my programs. I use it to monitor my program's progress as it works. I use it to log error messages from library methods that might be used in a server-side context (where there's no console on which to print a stack trace). Most importantly, logging is one of my main debugging tools. Though visual debuggers are handy on occasion, I've noticed that I can find more bugs faster by combining a careful reading of the code with a few well-placed logging messages. (I'm not quite sure why reading/logging seems more effective than visual debugging, but my current theory is that a visual debugger narrows your focus to a single thread of control through the program, so you tend to miss bugs that aren't on that thread.)

Logging is essential in server-side debugging, where, typically, no console exists, so System.out proves useless. For example, Tomcat sends System.out to its own log file, so you never see messages that are sent there unless you have access to that log file. More to the point, you probably want to monitor a server's performance from somewhere other than the server itself. Checking server logs is nice, but I'd much rather see the logs on my workstation.

One of the better logging systems around is the Apache Software Foundation's log4j project. It's more flexible and easier to use than Java's built-in APIs. It's also a trivial install—you just put a jar file and a simple configuration file on your CLASSPATH. (Resources includes a good introduction article to log4j.) Log4j is a free download. The stripped-down but adequate-for-the-end-user documentation is also free. But you have to pay 0 for the complete documentation, which I recommend.

This article will look at how to extend log4j by adding a new appender—the part of the system responsible for actually sending the log messages somewhere. The appender I discuss is a lightweight version of the socket-based appender that comes with log4j, but you can easily add your own appenders to put log messages into a database or LDAP (lightweight directory access protocol) directory, wrap them in proprietary protocols, route them to specific directories, and so forth.