After stating its value, let’s try to figure out logging requirements for an application. Java has a standard logging API in its new versions (java.util.logging). Log4J is also a well-known library for logging. We implemented a transparent “Logging Service” in our application framework. You may prefer some kind of logging implementations but there are some other important questions you have to answer in your application design which are what to log, when to log, how much to log, how to control logging and how correlate it with your exception system.
What to Log
Why not to log all exceptions? Some exceptions are managed exceptions which are thrown by application as a warning or as a validation error to the user. If all validation errors or application exceptions are included in logs, logs lose their usefulness since it would contain many entries hard to reach valuable entries. Here, we should discriminate exceptions if they should be logged. We used a Loggable mark interface to determine if it is included in logs. Another best practice is to have a single global exception handler. In this way, application developers don’t worry about logging of any exception they generate. A single exception handler means a single unified and neat exception logging.
For major components of application we may log lifecycle events like start, stop and restart. Some security-related events may be logged such as unauthorized URL access attempts, user logins etc. Some resource thresholds may be exceeded and should be logged.
In some codes, we should ask that “What could go wrong here in this code”. If this state occurs, we may throw an exception or log it (if we don’t want to interrupt current process) with some levels like Error, Warning or Information. For example if a connection is normally released while it is uncommitted, that info may be logged as uncommitted connection release that points some application code problems.
For some multi-step processes, we may create process log files so that we can inspect process progress. It behaves like a smart progress indicator telling you what is happening in the current step. Process logs may include errors, warnings and information.
In some applications, you may have some errors and can’t find why this is happening. You may add some debug logs into your code and redeploy it to diagnose the problem. Some chronic bugs deserve debug traces which can’t be detected in development environment.
In some conditions, we may want to get the SQL statement executed by an application. We should easily switch logging on without start/stop of system. Let’s say user complain about wrong report result when executing a report. If we don’t have a clue about that we may log SQL and trace it.
We may need what is coming from the user with full parameter details. To achieve this kind of logging we have to plug a log service in servlets and JSP pages.
I mentioned a BlackBox implementation in our applications in one of my previous posts. You may log executing thread information to that black box to figure out what may go wrong in a system crash.
Some Best Practices
Log entry should answer following questions:
Who(UserName), When (Timestamp), Where(Context, ServletOrPage,Database), What (Command), Result (Exception)
[ErrorHandlerName] UserName: userabc DatabaseName: ABC Timestamp: 15.07.2009 13:02:08 Context:Servlet Page: /prod/sales/SalesOrders.jsp Window: windwName Command: saveSalesOrder Exception: ShortDescriptionOfException