Friday, June 15, 2007

A Better logger hierarchy naming strategy for log4j

The common default when using log4j or commons-logging, are to create loggers with the fully qualified class name (FQCN) of the logging class, as the logger name. This makes it quick and easy to create loggers, without thinking too much about logger hierarchy (the assumption would be, that good package structure maps to a good logger hierarchy).

It is not neccessarily so though, that the package structure of the system maps to a good logger hierarchy structure.

If the FQCN is used, you will get a very fine grained hierarchy. A more simple hierarchy at the top, can make it easier to understand which parts to change levels on, to get the output you want.

An example
As an example, consider the application named "SuperApp". SuperApp" is a webapp, with a services and a dao layer. We could define only a few top-level logger names like this:
  • superapp.common
  • superapp.web
  • superapp.domain
Each logging class could use these as the first part of their name, and then append the simple class name of itself afterwards. Using this naming strategy will give you a very coarse level at the top of the hierarchy, while retaining a fine grained level at the leaf level.

Actually, I have few more top-level names, for example "", which represents something that is cross-cutting to a lot of the application. Also, I sometimes have an extra naming level after "", which is kind of "in the middle", just before the leaves.

What is good about this?
Often, when I debug, I find myself looking around in the hierarchy of loggers, turning something on here and there, to get the collected picture of the complete flow, that I want to follow. When using the naming strategy outlined below, I find it much easier to simply turn on a complete area of the system.

Also, when systems management are debugging, they have no or very little knowledge of the package structure of the application. They can better relate to the names, that are targeted the application, as above.

No comments: