Tuesday, December 31, 2013

2014 Overview of Logging in Java

Why do you even need a logging framework [In a nutshell] ?

  • Logging severity (Debug / Info / Error etc)
  • Different loggers for different tasks
  • Logging configuration in a single XML instead of all over your application
  • Lots of other reasons
Sorry, it is so obvious to me that I can't elaborate here any further

What sorts of logging components are there ?

  • Main Logging frameworks (use these to do the actual logging [log4j, logback etc])
  • Logging APIs (Facade): Due to several different logging frameworks, a need for a unified API has risen, and of course now there are several different "unified" APIs.
  • Logging Parsers: Components which enable us to read log streams (files, socket etc) conveniently as well as introduce advanced searching & filtering within the log files

Main Logging Frameworks

The main logging frameworks is what people usually refer to when talking about in app logging, and I suggest a rough division in this department:
Robust Logging Frameworks - You will want to use one of the logging frameworks in this department in any middle to big application you build as well as in any corporate application, you won't want anything that isn't robust and well tested.
Most notable frameworks in this section include: Java Util Logging, Log4j, Logback, Log4j2

Micro Logging frameworks

Not surprising at all, many small logging frameworks had sprung up to fill the void of those small applications that just want to have some logging without any fuss or memory footprint, in these frameworks you will find some that will consist of only 100 lines of code!, some that use static logging, and some which use only default configuration without any option for any configuration.
Notable ones is this category will include: MinLog (100 lines of code) and TinyLog (38k)

Logging APIs

Logging APIs serve several purposes
  • Unifying several different logging frameworks syntaxes, so the developer can learn only the APIs logging syntax while the API will work hard to adjust itself to each underlying logging framework's API. - This way the developer can use the same API library on several different projects even if each one uses a different logging framework.
  • Solving logging problems in one place (in the API) can workaround problems which still exist in the in the logging frameworks themselves, for example the infamous unneeded string concatenation in debug statements (logger.debug("User: " + user.getName()) - The java compiler will concatenate this string even when the logging severity is higher than debug - slf4j for example solves this problem).
  • No need to add logging implementation to libraries - When you build a java library you don't want to force the user of this library to any specific logging implementation, so just use a logging API which will enable the developer of the app using your library to decide on his own logging implementation (not to mention preventing logging library clashes).
The most notable java logging APIs are:
Apache Commons Logging

Logging Parsers

Regular java applications can spit out thousands of logging lines, most of them have the DEBUG severity, you can try and read them line by line (or grep the hell out of them), but I find a much more convenient way to use a special log parser which will understand the log file thus enable me to filter by severity or by the time & date as well as make it more readable by coloring the ERROR lines in red and the debug lines in grey.

Logging parsers possible features:

  • Can read log output from any logging framework (Jul, Log4j, Logback etc)
  • Can filter the logs
  • Can view the logs offline and @ runtime (tail –f)
  • Parses stacktraces and can jump to code (in dev environment)
  • Can view several log files using tabs
  • Up to date & Maintained project
As a thumb rule, the best option for the developer is to have a good log viewer incorporated into his IDE.
But if there is no decent log viewer in the IDE (IntelliJ Idea ?! [I opened a feature request for that in their Jira]), or you are trying to parse an offline log file, or you are just trying to view a log file on a production environment without any access to your IDE, then a good log parser can come in handy.

The most notable ones are:
OtrosLogViewer - Probably the best one out there.
LogSaw – Unlimited size log viewer (2012) [Input: File]
Lilith – Decent logs Viewer (2013) [Input: All]
JLogTailer – Tail –f for windows (old) [Input: file] - If you are into simplicity


Krzysztof Otrebski said...

OtrosLogViewer is now supporting IDE integration. You can click on stacktrace fragment and jump to code. If you hover a mouse on stacktrace, tooltip with code fragment will be displayed. You can check video teaser: https://www.youtube.com/watch?v=SbOFF56_7-A

avi said...

Thank you, OtrosLogViewer doesn't cease to amaze me.

They do really good work.