Apr
7
2006

There are things to love about java.util.logging…

An article by Glen

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 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…

About the Author: Glen Smith

9 Comments + Add Comment

Neil April 7, 2006 at 8:43 am

Using log4j and java.util.logging is similar because when java.util.logging was first announced log4j moved more closely to java.util.logging and then java.util.logging changed and became more like log4j. But, java.util.logging configuration is the big reason I don’t use it. log4j is just so much easier to configure.

Reply
James E. Ervin April 11, 2006 at 4:13 am

I just want to have methods like warning have the ability to pass in a Throwable directly. I hate to have to do log( Level.WARNING, …, throwable ).

Reply
Glen Smith April 11, 2006 at 5:21 am

Yeah. +1 on the exception story. The other one I miss from commons logging is if(log.isWarnEnabled()) rather than log.isLoggable(Level.WARNING)…

Reply
lhe April 12, 2006 at 3:43 am

anyone got an idea how you would configure java.util.logging to log user-specific information ?
e.g. when you got a servlet-based webapp with log4j i just use MDC/NDC and define the appender to output JSESSIONID with the log message. so i perfectly see what a single user did and am not overwhelmed by log output. but how would i do that in j.u.l ?

Reply
Ahsan July 6, 2006 at 6:34 am

i need some help, HOW can I stop the loggger util in JAVA from displaying the error messasges in the console window ?
pls help me out, thanks
-
ahsan

Reply
Glen Smith July 6, 2006 at 6:49 am

Ahsan,

You could programaatically set your handler to Level.OFF or edit your logging.properties file in your JRE directory.

# — ConsoleHandler —
# Override of global logging level
java.util.logging.ConsoleHandler.level=OFF

Reply
Ahsan July 6, 2006 at 6:58 am

Dear Sir,
I did the following

“edit your logging.properties file in your JRE directory. # — ConsoleHandler — # Override of global logging level java.util.logging.ConsoleHandle
r.level=OFF”

BUT, I got the following error, THE APP WORKED ALLRIGHT, but the following error appeared in the console !
“Can’t set level for java.util.logging.ConsoleHandler ”

Can you show me a way out ?

lso, how can I do the following

“You could programaatically set your handler to Level.OFF ” ??

can u show me the code snipet ?

Reply
Ahsan July 6, 2006 at 7:03 am

PROB WITH console error done with, solved , thanks, but how to do it programmatically ??

Reply
Ricuzzo May 4, 2011 at 12:18 am

You have to remove the parents handlers. So the only handlers left are the ones you specify in your code, just write this line:

logger.setUseParentHandlers(false);

Reply