views:

232

answers:

6
+4  Q: 

Advantage of log4j

What's the advantage of log4j over set System.out and System.err to output to a log file?

+1  A: 

my favorites (not all)

  • Ability to set parameters of logging in config, without recompiling
  • Ability to set the way log is written (from text file to SMTP sender)
  • Ability to filter by severity
Andrey
+1  A: 

Levels, formatting, logging to multiple files... A logging framework (even if it's java.util.logging) is really beneficial if there's a chance anything may go wrong while your code is running.

Quotidian
+7  A: 

At a high level, the win from Log4j over manual logging is that you can decouple your logging code from what you actually want to log and where and how you want to log it. Details about logging verbosity/filtering, formatting, log location, and even log type (files, network, etc.) are handled declaratively using configuration and extensibly via custom appenders, rather you having to code that flexibility yourself.

This is critically important because it's often hard for developers to predict how logging needs will change once their software is in production. Operations teams managing that software may need less verbose logs, may need mulitple logs, may need to ship those logs to multiple servers, may need to sometimes get really verbose data for troubleshooting, etc. And it's usually impossible for operations teams, if they need to change how logging works, to convince the developer to make big code changes. This often leads to production downtime, friction between operations and development, and wasted time all around.

From the developer's point of view, Log4j insulates you from having to make code changes to support logging, and insulates you from being pestered by people who want logging changes. It enables people managing your code to scratch their own itch rather than bugging you!

Also, since Log4j is the de-facto standard for Java logging, there are lots of tools available which can do cool things with Log4j-- furthermore preventing you and your operations teams from re-inventing the wheel.

My favorite feature is the ability to easily write appenders send data to non-file sources, like SYSLOG, Splunk, etc. which makes it easy to your app's custom logging into operations management tools your IT department is already using.

Justin Grant
Log4j was a defacto standard, but with java.util.logging, Commons Logging, and the many other logging frameworks that it supports, I'm not sure if that still holds true. Many open source projects that I've seen lately don't use log4j any more.
justkt
Log4j may not be the darling of Java logging anymore, but it is still far superior to System.out/.error. Commons Logging is also being replaced and JDK logging was always a case of 'not invented here' syndrome.
hbunny
Is this a duplicate or is it possible that this basic of a question hasn't been asked yet? I'm suspicious but willing to be surprised. My quick search didn't find an obvious dup but it wasn't an exhaustive search either.
Kelly French
+1  A: 

Log4j offers the ability to rotate your log files based on size and delete them based on quantity (logrotate), so your servers don't fill up their disks. Personally I think that is one of the more valuable features in Log4j.

Also Log4j is popular and understood by many developers. The last three companies I've worked at have all used Log4j in most projects.

sisslack
+1  A: 

log4j allows you to log to various resources e.g. event log, email, file system etc while allowing your application to remain decoupled from all of these resources. Furthermore, you get to use a common interface to log to all of the various resources without having to learn or integrate thier corresponding APIs.

Athens
+4  A: 

Actually, you should look into the slf4j facade these days, as it allows you to use {}-placeholders for the most concise statements. You can then use the appropriate logging framework behind slf4j to handle the actual treatment of your log statements. This could be log4j or the slf4j-simple which just prints out all of INFO, WARN and ERROR, and discards the rest.

The crucial observation you need to make is that the WRITING of log statements is done when the code is written, and the DECISION of what is needed is done when the code is deployed, which may be years after the code was written and tested. System.out.println requires you to physically change your code to get rid of them, which is unacceptable in a rigid write-test-deploy cycle. IF the code changes, it must be retested. With slf4j you just enable those you want to see.

We have full logging in the test phase, and rather verbose logging in the initial period of a production deployment, after which we go down to information only. This gives us full information in a scenario where debugging a case is very rarely possible.

You might find this article I wrote interesting. The target audience is beginning Java programmers, with my intention of giving them good habits from the start. http://runjva.appspot.com/logging101/index.html

Thorbjørn Ravn Andersen