log4j vs slf4j - Java

Log4J

Log4J has become the defacto stan­dard imple­men­ta­tion for log­ging, since it started of as a frame­work for log­ging since Java did not include a log­ging facil­ity itself.
It seems every devel­oper knows it and most projects and appli­ca­tion servers use it. So prob­a­bly I do not need to tell you about the log­ging lev­els TRACE, DEBUG, INFO, WARN and ERROR. The fact that you con­fig­ure the lay­out of the mes­sages con­tain­ing date and time, thread, class and method infor­ma­tion. The avail­abil­ity of file, data­base and e-mail appen­ders is also widely known and used. In short, this is the log­ging framework.
How­ever, Log4J is not actively main­tained any­more. It is widely spread and sta­ble accord­ing to the v1.2 web­site. Log4J was the pio­neer frame­work that intro­duced con­fig­urable log­ging. Intro­duc­tion of the log­ging level, the log­ger and the appen­ders, it’s all the guys that devel­oped Log4J who came up with that. But now it is stuck in its imple­men­ta­tion and no-one seems to be will­ing to cre­ate a new and improved v2.0.

SLF4J

SLF4J is not a log­ging imple­me­na­tion, like Jakarta Com­mons Log­ging, it is just a facade to pro­vide log­ging func­tion­al­ity in an appli­ca­tion with­out to much has­sle with dependencies.
How­ever, SLF4J is a cleaner depen­dency and more effi­cient at run­time than commons-logging. One of the rea­sons is SLF4J uses compile-time bind­ings instead of run­time dis­cov­ery of the other log­ging frame­works it inte­grates. That means that you can­not switch log­ging imple­men­ta­tions at run­time (and who would want that?). You con­fig­ure which of the com­mon log­ging frame­works you want to use explicitely.
Another dif­fer­ence with Com­mons Log­gins is that it does not only pro­vide bind­ings to many com­mon log­ging frame­works, includ­ing JCL, it also does the reverse. SLF4J includes bridges between other log­ging frame­works and itself. OK, but what does that mean, well if you want to use SLF4J with for instance Spring which uses the commons-logging frame­work, you will need to replace the commons-logging depen­dency with the SLF4J-JCL bridge. Once you have done that then log­ging calls from within Spring will be trans­lated into log­ging calls to the SLF4J API, so if other libraries in your appli­ca­tion use that API, then you have a sin­gle place to con­fig­ure and man­age logging.
When bridg­ing from Spring to SLF4J, you could choose Log4J as the bind­ing, which would result in 4 depen­den­cies (and off course the exlu­sion of the commons-logging depen­dency of Spring): the bridge, theSLF4J API, the bind­ing to Log4J, and the Log4J imple­men­ta­tion itself. There­fore most peo­ple using SLF4J choose Log­Back instead of Log4J. That requires only the bridge jcl-over-slf4j and log­back (and exclude slf4j-api from depen­den­cies that include that!).

Advan­tages SLF4J
  • No bloated code since we do not need the if(logger.isDebugEnabled()) line any­more to pre­vent sting con­cate­na­tion. (Note that other expen­sive calls made in the log state­ment might force us to put the if state­ment back!)
  • Para­me­ter­ized log­ging, eas­ily markup your log­ging mes­sage and pass the arguments.

Dis­ad­van­tages SLF4J

  • Class­load­ing prob­lems when appli­ca­tion servers still use Log4J and ship com­mons log­ging and Log4J libraries in their own server lib direc­tory. Use reverse class load­ing (IBM calles it ‘par­ent last’) to let your appli­ca­tion deter­mine the log­ging framework.
  • Some maven plu­g­ins use commons-logging which then cause conflicts.
  • Need two libraries as depen­dency, one for bridg­ing to slf4j and one for the actual implementation.
Source: http://mike.vanvendeloo.net/2011/05/06/logging-which-framework-to-choose-log4j-commons-logging-logback-slf4j

Comments

Post a Comment

Popular posts from this blog

EJB - Stateful vs Stateless

For  stateless session beans  the server can maintain a variable amount of instances in a pool. Each time a client requests such a stateless bean (e.g. through a method) a random instance is chosen to serve that request. That means if the client does two subsequent requests it is possible that two different instances of the stateless bean serve the requests. In fact there is no conversational state between the two requests. Also if the client disappears, the stateless bean does not get destroyed and can serve the next request from another client. On the other hand a  stateful session bean  is closely connected to the client. Each instance is created and bounded to a single client and serves only requests from that particular client. So happens that if you do two subsequent requests on a stateful bean, your request will be served always from the same instance of the bean. That means you can maintain a conversational state between the requests. At the end of the li...
Read more

Mirror binay tree - Java

public class TreeNode {     private TreeNode left;     private TreeNode right;     private Object value;     public TreeNode getLeft() {         return left;     }     public TreeNode setLeft(TreeNode left) {         this.left = left;         return this;     }     public TreeNode getRight() {         return right;     }     public TreeNode setRight(TreeNode right) {         this.right = right;         return this;     }     public Object getValue() {         return value;     }     public TreeNode setValue(Object value) {         this.value = value;         return this;     } } public class Mirror {     public stat...
Read more