logback - Java

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 inlogback.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.

Source: http://stackoverflow.com/questions/178215/log4j-vs-logback

-----------------------------------------------------------------------------------------------------------------------------------

Log­Back

Log­Back is kind of what should have been Log4J 2.0. It picks up where Log4J stopped. The cre­ator of Log4J also started the Log­Back project to cre­ate a new and improved version.
LogBack’s inter­nals are refac­tored to be faster, have a smaller mem­ory foot­print is bet­ter tested and has good doc­u­men­ta­tion. All improve­ments that we wel­come. Log­Back also imple­ments theSLF4J API natively and can eas­ily be used as a dropin replace­ment for Log4J (at least that is what they say, I will def­i­nitely need to try that).
Log­Back has some other cool new fea­tures, like the Siftin­gAp­pen­der, which is able to sep­a­rate your log­files on for instance a user ses­sion. It is also pos­si­ble to change the loglevel only for a cer­tain user, so you can trou­bleshoot a pro­duc­tion prob­lem with­out the log­file eat­ing up your lim­ited diskspace!
I/O failover is bet­ter, when­ever a file server fails tem­porar­ily, you do not need to restart your appli­ca­tion to start log­ging again.
The con­fig­u­ra­tion file is auto­mat­i­cally reloaded upon mod­i­fi­ca­tion, a nice fea­ture for appli­ca­tion servers and JEE appli­ca­tions. Another nice addon is the logback-access mod­ule for appli­ca­tion servers. This addon adds the abil­ity to see HTTP-access log­ging to your application.
There is also the logviewer Lilith, com­pa­ra­ble to Chain­saw for Log4J, but it can han­dle large log­files much better.
When log­ging it is a best prac­tice to check the level (when using com­mons log­ging and/or Log4J) using code sim­i­lar to this:
if( logger.isDebugEnabled() ) {
  logger.debug( "User with account " +
    user.getAccount() + " failed authentication; " +
    "supplied crypted password " + user.crypt(password) +
    " does not match." );
}
Within Log­Back it would be much sim­pler, more read­able and cleaner. The pre­vi­ous exam­ple would look like this:
logger.debug( "User with account {} failed authentication; " +
    "supplied crypted password {} does not match.",
    user.getAccount(), user.crypt(password) );
While writ­ing down all these fea­tures, I won­der why we are all still using Log4J. I will need to look into this frame­work soon!

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