I admit it. This week is the first time I’ve ever used java.util.logging. I’ve pretty much always used commons logging and log4j for all my logging needs since one of them was already a dependency in a supporting library, and I’ve never really had a reason to look elsewhere.

Till now…

I’ve had reason to work on some code that integrates into Websphere’s Member Manager stuff. This code is way down in the WAS stack, and if I wanted to use log4j, I’d have to drag it into /lib/ext…. which means that everyone on that app server is now using my version of log4j. Not so sweet.

My next thought was to use Commons Logging (JCL). WAS5.1 uses commons logging internally, and I could get it into WAS6, but I found there are all sorts of classloader issues with it when /lib/ext comes into play. So that was off the list.

Finally I did some digging and discovered that WAS6 has switched to java.util.logging for all its logging goodness. Read a few good [

articles](http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/overview.html) and I was good to go. Had to get used to the idea of Loggers, Handlers and Formatters and how they hung together. but it wasn’t much of a switch really. You end up doing stuff like: 

Logger myLogger = Logger.getLogger(myClass.class.getName());

along with a:

if (myLogger.isLoggable(Level.FINE))
    myLogger.log(Level.FINE, "Try catching this", e);

Seems that the log method does some reflection to see what method are logging from. Not sure of the performance implications of that one under load… the IBM docs recommend using the logp() version of the call for just that reason… but we’ll see. The basic Formatter is pretty average (two line log messages!), but it’s pluggable so you can probably simulate a log4j console appender if you were that keen. The standard ConsoleAppender goes to stderr which I found a bit annoying and haven’t work out how to fix just yet.

The only bit I found generally confusing was how you actually configure it declaritively. You can edit logging.properties in your JRE, but that’s a little overkill. You can supply -D args to your command line for a config file or config class… but that’s not going to work for my /lib/ext story.

Then I found that WAS6 provides cute ways to modify your log levels dynamically on a per logger basis straight from the admin console. This is ideal for a /lib/ext app where you want to wind up logging every so often and debug a problem… but you don’t want an outage on the app server.

Anyways… I’m not sure java.util.logging deserves the bad wrap that it gets. It certainly doesn’t have the prebuild flexibility of log4j with DailyRollingFileWithAChocolateToppingLogAppenders, but for the basics it does plenty (including the equivalent of a RollingFileAppender), and definitely hits the sweet spot for Websphere /lib/ext uses.

Worth exploring…