log4j vs logback [closed]

Question

We are using log4j behind a selfmade wrapper. We plan to use much more features of it now.

Should we update to logback ?

(I mean the framework not a facade like SLF4J)

Nares

logback sounds very similar to jakarta commons logging - what are the main differences? – Remedial

SLF4J (which is the facade) sounds similar to commons.logging. The main difference is that SLF4J is using static binding while commons.logging is using some resolution strategy. Logback (the "native" (i.e. there is no additional wrapper layer) implementation of the facade) is comparable to LOG4J but has a richer API. – Foulness

SLF4J is a facade framework which makes it easier to switch from one framework to another Checkout comparison between all frameworks here – Kalikalian

Answer 1

Logback natively implements the SLF4J API. This means that if you are using logback, you are actually using the SLF4J API. You could theoretically use the internals of the logback API directly for logging, but that is highly discouraged. All logback documentation and examples on loggers are written in terms of the SLF4J API.

So by using logback, you'd be actually using SLF4J and if for any reason you wanted to switch back to log4j, you could do so within minutes by simply dropping slf4j-log4j12.jar onto your class path.

When migrating from logback to log4j, logback specific parts, specifically those contained in logback.xml configuration file would still need to be migrated to its log4j equivalent, i.e. log4j.properties. When migrating in the other direction, log4j configuration, i.e. log4j.properties, would need to be converted to its logback equivalent. There is an on-line tool for that. The amount of work involved in migrating configuration files is much less than the work required to migrate logger calls disseminated throughout all your software's source code and its dependencies.

Unbidden

Its a reare opportunity to talk to the developer of such a widely popular software. Thanks Ceki for log4j. – Somato

Disclaimer: This guy is the original developer of all of Log4j, SLF4J and Logback. But don't work anymore for Log4j. – Recuperate

Answer 2

Should you? Yes.

Why? Log4J has essentially been deprecated by Logback.

Is it urgent? Maybe not.

Is it painless? Probably, but it may depend on your logging statements.

Note that if you really want to take full advantage of LogBack (or SLF4J), then you really need to write proper logging statements. This will yield advantages like faster code because of the lazy evaluation, and less lines of code because you can avoid guards.

Finally, I highly recommend SLF4J. (Why recreate the wheel with your own facade?)

Abet

Note: The log4j project does not consider log4j deprecated. – Rutheruthenia

The terminology should be clarified; unequivocally, the author of the log4j project considers logback to be the successor of log4j. It's the same author of both projects, so his opinion should carry some weight; the "log4j project" itself doesn't really "consider" anything. The current group of people associated with log4j have diverging opinions (some actually agree, some unsurprisingly disagree). With a little more history behind us (3 yrs after the original comment), SLF4J + Logback do continue to gain ground over Log4j. – Agripina

@michael_n Please note that Log4j 1 was NOT written by a single person. Its wrong to say the "same author". Ceki is an important author, not doubt, but not the only one. In fact a lot of people helped making Log4j 1 what it is. – Leshalesher

@Leshalesher "was NOT written..." of course, that should be implied for any mature apache project (and my qualification, "the current group of people associated with log4j"); nonetheless, if i could edit the comment, i would say "originally authored", as the wikipedia article also states. Re: "In fact a lot of people helped making Log4j 1 what it is" , that is absolutely, equivocally true (i.e., for better or worse); and also, in some small way, contributed to the inception of slf4j+logback :-) – Agripina

So, what's in it for you all to be fighting over this or that logging library? Why are we trying to kill/promote libraries? At least provide some rational reasoning WHY one is better than the other. God, Stack Overflow is a mess. – Welcome

Agreed, Manius. There is a much more reasoned discussion at #179336 – Renege

Answer 3

In the logging world there are Facades (like Apache Commons Logging, slf4j or even the Log4j 2.0 API) and implementations (Log4j 1 + 2, java.util.logging, TinyLog, Logback).

Basically you should replace your selfmade wrapper with slf4j IF and only IF you are not happy with it for some reason. While Apache Commons Logging is not really providing a modern API, slf4j and the new Log4j 2 facade is providing that. Given that quite a bunch of apps use slf4j as a wrapper it might make sense to use that.

slf4j gives a number of nice API sugar, like this example from slf4j docs:

logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);

It's variable substitution. This is also supported by Log4j 2.

However you need to be aware that slf4j is developed by QOS who also maintain logback. Log4j 2.0 is baked in the Apache Software Foundation. In the past three years a vibrant and active community has grown there again. If you appreciate Open Source as it is done by the Apache Software Foundation with all its guarantees you might reconsider using slf4j in favor to use Log4j 2 directly.

Please note:

In the past log4j 1 was not actively maintained while Logback was. But today things are different. Log4j 2 is actively maintained and releases on almost regular schedule. It also includes lot of modern features and -imho- makes a couple of things better than Logback. This is sometimes just a matter of taste and you should draw your own conclusions.

I wrote a quick overview on the new Features of Log4j 2.0: http://www.grobmeier.de/the-new-log4j-2-0-05122012.html

When reading you will see that Log4j 2 was inspired by Logback but also by other logging frameworks. But the code base is different; it shares almost nothing with Log4j 1 and zero with Logback. This lead to some improvements like in example Log4j 2 operates with bytestreams instead of Strings under the hood. Also it doesn't loose events while reconfiguring.

Log4j 2 can log with higher speed than other frameworks I know: http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html

And still the user community seems to be much bigger than Logbacks: http://www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html

That all said the best idea is you choose the logging frameworks which just fits best to what you want to achieve. I would not switch a full framework if I would disable logging in production environment and just perform basic logging in my app. However if you do a bit more with logging just look at the features which are provided by the frameworks and their developers. While you get commercial support for Logback through QOS (i heard) there is currently no commercial support for Log4j 2. On the other hand if you need to do audit logging and need high performance provided by the async appenders it makes a lot of sense to check log4j 2.

Please note despite all comfort they provide, facades always eat a little performance. It's maybe not affecting you at all, but if you are on low resources you may need to save everything you can have.

Without knowing you requirements better it is almost impossible to give a recommendation. Just: don't switch just because a lot of people switch. Switch only because you see value of it. And the argumentation that log4j is dead doesn't count anymore. It's alive, and it's hot.

DISCLAIMER: I am currently VP, Apache Logging Services and involved in log4j as well.

Leshalesher

Answer 4

Not exactly answering your question, but if you could move away from your self-made wrapper then there is Simple Logging Facade for Java (SLF4J) which Hibernate has now switched to (instead of commons logging).

SLF4J suffers from none of the class loader problems or memory leaks observed with Jakarta Commons Logging (JCL).

SLF4J supports JDK logging, log4j and logback. So then it should be fairly easy to switch from log4j to logback when the time is right.

Edit: Aplogies that I hadn't made myself clear. I was suggesting using SLF4J to isolate yourself from having to make a hard choice between log4j or logback.

Neuropathy

I know SLF4J. But i asked for the logging framework not for the facade! – Inclinatory

Apologies. What I was suggesting was that if you were using SLF4J instead of your own custom facade, then switching from log4j to logback would be less painful? – Neuropathy

What is the source of that citation? Commons logging is a tried and tested component. I've never had any memory leaks with it. – Melessa

@KshitizSharma - from the SLF4J documentation link I provided: slf4j.org/manual.html – Neuropathy

Answer 5

Your decision should be based on

• your actual need for these "more features"; and
• your expected cost of implementing the change.

You should resist the urge to change APIs just because it's "newer, shinier, better." I follow a policy of "if it's not broken, don't kick it."

If your application requires a very sophisticated logging framework, you may want to consider why.

Dimaggio

Answer 6

Mature project or even project deep into development stages would probably loose more than gain from such upgrade, IMHO. Logback is certainly much more advanced in an array of points, but not to an extent for complete replacement in a working system. I would certainly consider logback for a new development, but existing log4j is good enough and mature for anything already released and met end user. This is very subjective, you should see cost yourself.

Kuntz