Log4j : Debugging Concepts - Part-1

Who are you? If you or your client once discovered a bug in your application and never being able to reproduce it again. If you once felt that your too late discovered application bug let you down by reducing your reputation in front of your client. If you are not completely satisfied with the traditional debugger you are using or even have no access to a debugger at all. If you ever set in front of your running application wondering what it's doing now and what exact parts of it are currently being executed. You are already familiar with Java know how to compile your code, and how to use JDK. If you are any one of the those people then please read on ... logging is for you!

Introduction

Every time we attend a meeting or a conference that is some how related to debugging, we frequently hear the famous statement: 'Fixing bugs is not easy!'. Our experience shows that fixing bugs is rather easy. What makes people think like that is they topically mix discovering the location of a bug inside their code and actually fixing it. If you are to discover where your bug is, then fixing it is no more than doing some changes in a line or two of code. Very rare bugs that can cause dramatic / architectural changes to you application. Logging is concerned (among few other concerns) with the process of discovering bugs and can be a great aid for this purpose.

What is logging?

Logging is one of the low level technologies that can be used for debugging your code. Like a debugger watch which enables you to view variables values, logging can be an aid for you to print out your variables current values for example. Logging in it's simplest form involves placing overhead statements in your code that prints out a value of a variable or indicates the occurrence of an event of particular interest to you.

When to use logging?

Logging is not a replacement for the well established and the standardized testing activities that are well known in software engineering. If you already implemented your test plan that was successful enough that aided you in the discovery of most of the bugs in your application, then logging is exactly for you. After all this extensive testing you cannot be absolutely sure that your application is 100% bug free and will never fail. This is where the use of logging can provide you with continues monitoring for your application so that you are always sure about what is happening inside your application. 

Egyptians say: "You can sometimes hit two or more birds with only one bullet". If you want to add auditing or profiling to your application then logging can be used to achieve this while in the same time aids you in testing and debugging your application.

Ever wondered why should you use log4j; Why logging is useful?

Logging is typically confused with the use of tradition debuggers. Here we present a set of important facts that are vital to your understanding of why logging is important in some cases. Although logging can be considered as one of the techniques that can be used for the purpose of debugging a particular application, it has several significantly distinct features if compared to the use of a traditional debugger. In the following table we list some of these significantly unique features to give you the skill judging which of them is appropriate in which scenario: 

Aspect	Logging	Using a traditional debugger
Attendance	Can be performed by your  application while it's unattended. In other words, you can safely leave you application running and later analyze it's output log files for whatever information you need.	Must be attended. Some professional must be setting all the time monitoring the debugging sessions and judging the behavior of the application being debugged.
Information display	The display of the debugging data can be as sophisticated, detailed, and formatted as you like. Do not consider it a strange case to have graphs for example as an output for your application logs.	You are limited to the display options that are available inside your debugger. For most cases these options are rather limited if compared to the unlimited flexibility of information display in customized logging.
Ability of further information analysis	Can allow exporting logging data to many third party tools outside the application being debugged for proper display and analysis. For example you can export data from your application logs into spreadsheets and relational database management systems, hence benefiting from their rich analysis tools. This can be particularly useful when you need to analyze huge amounts of data that cannot be analyzed by a human in front of a screen as in the debugger case.	The data you are seeing on the screen while in a debugging session is highly volatile and has the life only of the debugging session. The maximum you can do is to sometimes copy data from your debugger to another analysis application which is incomparable to the data transfer capabilities of the logging case.
Platform dependence	You can simply, seamlessly, and transparently analyze your logging data on a machine that is totally different from the machine on which you run your application (difference can be in hardware, operating system, ... etc). This is particularly useful when the machine on which you have to run your application is not equipped with the analysis tools you need to analyze your logs. With reference to this feature, logging can be considered to be 100% platform independent.	A debugger designed for a particular platform cannot be used on a different one. With the exception of some limited remote debugging cases, the debugger must be running on the same machine on which your application is running. This assumes this particular machine has a debugger suitable for it; some platforms have no debuggers at all.
Alteration of the useful code	This is one of the disadvantages involved when using logging. You have to alter your useful code with extra overhead lines of code to implement a proper logging mechanism.	If a debugger is available, you can immediately debug your application without altering a single line in it's code.
Availability	Always available. If you can write an application and run it on a particular platform, then you are essentially able to implement logging for your application on this platform. Platform is not an issue at all in logging. Sometimes logging is used for a single reason: There is no debugger available for this platform.	There must be a debugger that is designed specifically to run on the particular platform under which the application being debugged is run.
Mobility	You can send your logging data to anywhere for later unattended analysis.	A professional must be setting in person in the front of the debugger while in the debugging session. While you can overcome this using remote desktop tools or a remote debugger, it's apparent it's a reduced flexibility if compared to the logging case.
Debugging special applications	In certain cases the use of debuggers is not feasible even if debuggers are available. Take for example the debugging of a graphical application in which the switching from the graphics display adapter mode in which the application is running to the mode in which the debugger can be run is not practically possible. Take as another example the debugging of real time system applications in which data acquisition is performed very fast that tracking it using a debugger is not practical at all. In the first case, the silent behavior of logging to files is very desirable. In the later case the ability of very quickly logging the data being collected to log files is highly desirable as well. Several similar examples exist like distributed applications and multithreaded applications.	Even if available for a particular platform, its use can be impossible at all or at least impractical for applications of special behavior.
Performance	The application performance can be affected by adding the overhead logging lines to your code. By careful design and the use of the proper logging technology, you can reduce this performance degradation to forgivable amounts.	With exception to the specially built debugging version of an application, debuggers can be considered to place a little change in application performance.
Code lines granularity and control	You can have clues about which part of your application is being executed now but of course not to the same fine level as in the traditional debugger case. You cannot have a control over the code being run other than the control that is built by the developer of the application being debugged.	You can execute your code while monitoring what code is being run to any granularity, line by line or even instruction by instruction. You have finer control and can for example bypass certain code lines, repeat other, and even you can stop your application at any time.

Although we did not list every possible aspect of this comparison you can take the flavor of when logging is more applicable than the use of traditional debuggers. When it's a about a machine working by its own generating massive amounts of data for later analysis then we are talking about logging. When it's about an interactive session that is attended all the time and a human is exist to monitor the session's humanly readable data then we simply use traditional debuggers. An important last distinction between the two scenarios is that you can opt for your application to continue forever with the logging built inside it but on the other hand you will not be able to run your production application version under a debugger every time forever. 

An absolute reason for which you will be convinced that logging (in certain cases) is far more suitable than the use of traditional debuggers is the answer of this question: "Who know more about your code? Your code itself or a traditional debugger?” When you are debugging by logging then your code is taking care of it and your code is of course more aware about itself than any possible traditional debugger --- Judge by yourself!

So, up to now we are recommending logging and exposing its advantages. The important question now is whether or not all of these advantages come for free? Of course you have to pay. The major inconveniencies involved in employing logging are the decreased application performance and (naturally) the extra effort of implementing logging inside your code. In a traditional debugger you simply plug your application into the debugger and you are done. In logging you certainly need more efforts. If logging is implemented carefully, then its effect on application performance can be made of minimum significance.