Log Organization

The Avalon framework and team advocate a category based approach to organizing loggers as opposed to a class name based approach. There is a very good reason for this. First is that categorization allows you to put information of like kind in one location. Second, it allows you to turn on and off an entire category of log messages.

The arguments for the class name based logging usually fall under these assumptions:

1. There is an implicit match between a class and a category.

2. It makes it easier to get debug information from a specific class if we are having problems with it.

3. The configuration file can handle the actual mapping of classname to log file.

While these arguments have their point, so does a strict category based logging approach:

1. You can narrow your log messages farther than simple class granularity. This way you can get information from the part of the class that really needs it.

2. More often than not, a group of classes make up a Component. In most cases, the Component is what you are really interested in--not the individual classes.

3. It is easier to manage a configuration file with only a few categories that are bound to Component instances during runtime you can separate the log files by who is concerned with their contents.

Log Category Organization

I would argue that it is a mistake to use only one category for all logging. The reason is that you will inevitably need to turn on and off a whole class of messages. Another reason is that you will need at least one category for each log file you have. One effective approach is to separate your logging needs into roles and classifications.

If you have already decomposed your system into Components, then you have one set of categories defined. I would use a shorthand name for the category names for simple reference (e.g. "resource" instead of "org.apache.avalon.excalibur.resource.ResourceManager"). The simplified names can be used for a broad set of classes. Using the same example, the name "resource" implies the Resource class, its manager, and anything that is directly associated with the concept of a "resource".

You can also use classifications as a specialization of the main role classification. For example, all ComponentManager code would have a category name of "component". This would allow you to have a Category manager for the aforementioned "resource" infrastructure. Typically classifications are sub-categories. In this case, the full name of the "component" category would be "resource.component". This means that we are referring to the "component" classification for the "resource" role.

Most of your logging needs can be organized into this two dimensional cross-section of Role and Classification. Roles are best for main categories due to their logical separation. Typical classifications are "component", "security", and "pool". These same classifications can be used as standard sub-categories of the different roles. This way your log entries can have fine-grained control that is logically organized.

Log Writing

The mechanics of log writing can vastly affect the performance of your code. For instance, if you concatenate several strings together in your log messages, the Java Virtual Machine converts the concatenation to a StringBuffer, and performs the expensive toString operation on the result. The Logger interface provides a mechanism to optimize away these conversions when they are not needed.