migrating a project from log4j to slf4j+log4j

13
votes

I have a large web project that uses log4j directly, together with many 3rd-party libraries and a mix of logging libraries.

  • our code base - uses log4j directly.
  • Hibernate - uses slf4j, and the slf4j-log4j binding.
  • Spring - uses commons-loggings. Thus, it uses the jcl-over-slf4j bridge api, slf4j itself, and slf4j-log4j binding.
  • Other numerous libraries, using either commons loggings or log4j.

I am considering migrating our own code base to slf4j api, but I am not sure if the benefits are strong enough and worth the effort. Currently I am aware of the following benefits:

  • Cleaner api.
  • Performance improvements - namely the ability to use parameterized logging methods.
  • Ability to switch easily to logback in the future (currently logback is out of the question).
  • No need for additional jars, since I already have them.

Are there any other benefits? Are there any drawbacks that I am not aware of yet?

2
javalogginglog4jslf4j
Spring doesn't use SLF4J, it uses Apache Commons Logging – skaffman
Java logging and their 350,000 different implementations: what a PITA. Good luck @Yoni. – Tomas Narros
Personally I think the String.format like semantics of the logging methods worth some effort. No more isDebugEnabled() for expensive logging calls :) – extraneon
@skaffman, perhaps I am using the jcl-over-slf4j bridge for spring as well. I have to admit I don't remember it precisely, and I don't have access to the code right now. – Yoni

2 Answers

6
votes

The only benefit I see for switching, is that you can funnel all the logging frameworks through only one framework, which might simplify your configuration.

Probably the main reasons why I moved to slf4j (this only applies to slf4j + logback) is that you can reload the configuration via JMX, which is GREAT when you have a problem that disappears with a server restart.

5
votes

For me, there were four "killer" features which were worth the pain in moving over to Logback, on top of the ones you already mentioned (I personally switched my current major project, working flawlessly):

  • Automatic reloading of config files. This is awesome for production systems. If you just want to set "debug" to one class, but not bring down the whole system, this one is priceless.
  • Ability to use include files in the config. This allows you to have a "master" set of logging settings for all your services/JVMs, and then you can specify any packages which might require special processing. We have about ~10 services currently, and they have all a large, but mostly similar, copy of log4j.xml. We're now changing it to one master logback config file, and have that file included in every service's logback config file. The master file will still be large, but the service-specific ones should be very small. Much more maintainable.
  • Conditional processing. This way you can specify things like "if QAServer => then set logging levels to "DEBUG", else "INFO". Again, great for having a single config that doesn't have to change between production and dev/QA servers.
  • Automatic compression and deletion of old log files. You can specify how many archived files you want to keep, and optionally compress them. After creating the n+1 file, it will detect that there's one too many, and will delete the oldest one. Again, configurable per file/service, no need to do anything system-specific (batch files and/or scripts).

By the way, after doing this change, it's trivially easy to switch back to log4j. Since migrating to Logback required using SLF4J, which Log4j also supports, switching back and forth only requires you to choose which jar file to drop (Log4j's or Logback's). As long as the corresponding log4j.xml or logback config files are in the classpath, logging will work correctly.