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.

The issue is made more complex by the fact that Log4J has a dot-notation hierarchical category system, but is most often used for the package/class hierarchy, and not by explicit names.

Avalon Logging is an interesting approach, where the component declares the Loggers it want to have available in the Type descriptor, and the container satisfy this need, by mapping those categories to the underlying logging system's categories. Furthermore, you set the priority for each such category in the block.xml, which can be overridden in the config.xml.

Log Category Organization

We 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. For instance, a network connection component may have logging roles of "connections", "traffic" and "client".

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 role. Typically classifications are sub-categories. For instance, 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. It is fairly important for performance reasons to have all your code following the following pattern;

    if( logger.isDebugEnabled() )
        logger.debug( "Some debug message..." );
     :        
     :     
    if( logger.isInfoEnabled() )
        logger.info( "some complex info message" );
     :        
     :     
    if( logger.isWarnEnabled() )
        logger.warn( "WARNING! " );
     :        
     :     
    if( logger.isErrorEnabled() )
        logger.error( "We had some problems..." );

Finally, each logging system supports different types of log output destinations and formatting. It is important to study the performance impact on each of these features. For instance, Log4J can provide source file and line number of where the log message was called from, which is VERY expensive call, although very convenient in debugging environments, it must be taken out during production. Another example is to investigate the possible speed improvements of using asynchronous targets and buffered streams.

It is not uncommon for many applications that unchecked logging result in negative speed impacts of a magnitude or more.