CODEWITHSUNDEEP
javalogginglog4jslf4jlogback
Michael
Michael

Reputation: 10303

Should I use slf4j as wrapper for logback?

Suppose there is an application, which uses log4j directly, i. e. without slf4j or any other wrapper. Now I would like to replace the log4j with logback. Should I use slf4j (or any other wrapper)? What is considered "good practice"?

Upvotes: 3

Views: 1308

Answers (4)

Thorbjørn Ravn Andersen
Thorbjørn Ravn Andersen

Reputation: 75426

There is one very good reason for using the SLF4J api regardless of actual logging backend, namely the

 log.debug("Foo: {}, Bar: {}", foo, bar);

parameter construct. Log4j always need a full string to log, which is why you need surrounding ifs to see if the statement is enabled for an expensive string. SLF4J do not call foo.toString() or bar.toString() before doing the check, so disabled calls are cheap.

Hence I would suggest migrating your source to slf4j and use the appropriate bridge in the slf4j download to use log4j as the backend. This will allow you to continue as you do now, without further changes. You can then switch backend to logback if you need to.

Upvotes: 1

Ceki
Ceki

Reputation: 27510

As mentioned by Evgeniy Dorofeev, logback natively implements the slf4j-api. This means that invocation of a logback logger via the slf4j-api, that is via an instance of org.slf4j.Logger incurs no overhead at all. You could directly invoke loggers of type ch.qos.logback.classic.Logger instead of org.slf4j.Logger but doing so does not provide any advantages but will probably make it harder to migrate to a different logging framework if and when you chose to do so.

By the way, slf4j is not a wrapper for logback as logback is implemented in terms of the slf4j-api.

To ease migration to SLF4J, there is a tool for migrating source code to slf4j. For code which can not be modified by you, there are bridges for log4j, java.util.logging and commons-logging.

Upvotes: 2

Ian Roberts
Ian Roberts

Reputation: 122414

You may be able to migrate with no code changes at all, using the log4j-over-slf4j.jar instead of the "real" Log4J one. This provides the same API as Log4J to its clients, but directs the logging calls to SLF4J, which in turn can send them to logback.

But if you have the option of modifying the code then I would recommend changing it to use SLF4J, and you can then swap in any back-end as required (logback, log4j, etc). One thing you must not do is try and combine log4j-over-slf4j with the Log4J backend...

Upvotes: 1

Evgeniy Dorofeev
Evgeniy Dorofeev

Reputation: 136132

You surely should use slf4j API, if you later decide to go back to log4j or something else you will only need to change slf4j bridge, and your application logging code will work without changes. Besides, if you visit http://www.slf4j.org/ you will see that slf4j considers Logback as its native implementation, Logback actually natively implements the SLF4J API.

Upvotes: 4

Related Questions