migrating a project from log4j to slf4j+log4j

Question

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.

Answer 1

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.

Answer 2

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.