Techie Madness

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

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