Andreas Schaefer's Blog

To the Hell with the JDK Logging

Based on the success of Log4J Sun for sure had to go ahead and add its own version of it as JDK logging making our life miserable. I was complaining a lot about that at the LA-JUG but today it reached a point where I really had enough to start ranting here.

Currently I am working with Glassfish and beside some other sticky points with it I ran into an issue with the logging or better the absence of logging. What I want to do is to deploy ServiceMix based JBI components as well as our own components to deploy on OpenESB that runs on Glassfish. Something is not working as expected and so I started to look into the log files but could not find any log entries from our applications. Finally I figured out that my component is using Log4J instead of the JDK logging that Glassfish is using. This is because the component contains Log4J archive because one of the other components needs it. On the other hand Log4J is not creating the log file and so the log entries vanishes. Now I cannot remove Log4J because some of the components used needs it but I cannot make the commons logging to use the JDK logging in my component. Maybe I am just stupid enough not able to fix that but using a logging framework should not be rocket science. Right now I started to use System.out.println() just to see what is going on, ridiculous!

Now how to could this be fixed? Except the Glassfish community is striving to shut out any component that is using Log4J one should expect that Glassfish could provide a Log4J wrapper that takes the Log4J statements and redirects it to their JDK logging. As the JBI components show the issues from class loading making it impossible for Apache's Commons Logging to select the correct logging framework and even when only CL is used it may not work as expected.

Comments

• Commons Logging loves Log4j. If you don't want it to use the latter, try replacing commons-logging.jar with commons-logging-api.jar everywhere. And make sure you don't leave commons-logging.jar in a different classloader to log4j.jar, because if Commons Logging finds Log4j in the context classloader it will try to load it with its own classloader.

  I'm not Commons Logging's biggest fan.

  It sounds like what you're looking for is SLF4J, which can replace Log4j and log to JDK logging without any hassle.

  Posted by: nzcarey on August 28, 2007 at 02:42 PM

• i would exactly say the opposite as "To the Hell with the Log4j"

  Posted by: ahmetaa on August 28, 2007 at 05:11 PM

• I really do not see any reason for three or four different logkits for Java at all. From an engineering point of view, it should be a minor effort to integrate all existing frameworks into a single one, so that everybody is pleased for the next decade. Logging is a commodity. All you need is a simple interface for the application programmer, a flexible configuration mechanism for administrators, and a clever plugin architecture for different output channels. This is not rocket science. I'd really appreciate a JSR for an enhanced java.util.logging, where the log4j guys have a few drinks with a bright JSE representative and a few JEE container people until they agree on a single interface...And don't invite Ceki Gülcü, he will invent a slightly different thing anyway ;-)

  Posted by: scotty69 on August 28, 2007 at 06:02 PM

• i think the JDK logging is more OO-ish (where you customise by inheritance, overriding), whereas Log4J is parameterised using strings, which i don't like. I wish all projects would move towards JDK logging, i really do! PS. Log4J has debug() - that's just wrong - one should never admit the possibility of having bugs! ;)

  Posted by: evanx on August 28, 2007 at 09:58 PM

• Log4J is one of the most obvious excess of dependencies culture that dominated frameworks design last few years.. I already blogged about that, but it seems it is getting worst every day.
  Some popular frameworks just force you to download and ignore thousand of files.. :(.

  Posted by: felipegaucho on August 29, 2007 at 03:57 AM

• I started a web service project for logging. https://wslogging.dev.java.net/

  Posted by: zoetsekas on August 29, 2007 at 05:53 AM

• I am with ahmetaa. For better or worse, java.util.logging is part of the SDK. log4j may be a little bit better (or not--I never saw any convincing evidence one way or another), but it isn't so much better that it is worth paying for the dependency. I heard some people grouse that Sun didn't consult the community when it put java.util.logging into the SDK. Ok, perhaps that wasn't nice, but that was way back when. Time to move on...

  Posted by: cayhorstmann on August 29, 2007 at 10:48 AM

• i put commons-logging, log4j and a properties file on the classpath and log away. not sure why everyone hates it so much. i think some people have too much time on their hands to think about things.

  Posted by: ilazarte on August 29, 2007 at 11:22 AM

• I heard some people grouse that Sun didn't consult the community I believe there was some consultation, but they evidently were unable to reach agreement.

  Posted by: mthornton on August 29, 2007 at 12:17 PM

• You can find a short comparison here: http://articles.techrepublic.com.com/5100-22-1046694.html

  There used to be a great article by Ceki Gulku (the father of log4j) at http://jakarta.apache.org/log4j/docs/critique.html but the link is dead :-(

  Posted by: dserodio on August 30, 2007 at 07:41 AM

• @ilazarte: That's fine until you have to deploy your app to an app server, hot-redeploy it, etc. Then it begins to hurt.

  Posted by: dserodio on August 30, 2007 at 12:12 PM

• And this is a problem with JDK logging because....?

  Posted by: fiath on September 03, 2007 at 04:49 AM

This work is licensed under a Creative Commons License.