Re: Advice requested on best way to implement log4* to support non-hierarchal categories

We use Log4J and Log4CXX in certain products we've made.  Our usage is simple:

Logger.Hierarchy.Names        -> for normal logging
Alerts.Logger.Hierarchy.Names        -> for ALERTS meant for Network Operations Staff, Technicians etc. (usually important msgs)
Statistics.Logger.Hierarchy.Names        -> System operations stats

--- PS. I can't post to the Log4J list as I'm not a subscriber. ---

Renny Koshy
President & CEO

--------------------------------------------
RUBIX Information Technologies, Inc.
www.rubixinfotech.com

Curt Arnold <carnold@xxxxxxxxxx> 01/19/2005 05:38 PM Please respond to "Log4CXX User"

To:        Log4J Users List <log4j-user@xxxxxxxxxxxxxxxxxx>         cc:        Log4CXX User <log4cxx-user@xxxxxxxxxxxxxxxxxx>         Subject:        [SPAM] Re: Advice requested on best way to implement log4* to support non-hierarchal categories

I'm continuing the initial cross-posting just to tell anyone interested 
in following or responding to the thread to do so on 
log4j-user@xxxxxxxxxxxxxxxxxxx

I think that you need to design your use of the log4X frameworks so 
that they can readily evolve as you discover the best hierarchy for 
your applications.  The hierarchical metaphor used in the log4X is 
useful, but not perfect, for configuring logging.  Even a bad hierarchy 
is better than individually configuring each logger.

The logging hierarchy should be designed to make typical configurations 
simple to express.   Configuration precedes collection which precedes 
analysis.  If you make configuration or collection difficult, you won't 
have anything to analyze.

You should should consider the audiences for the log messages and the 
frequency of the potential logging requests and their impact on 
performance.

The most common "audience" for log4X messages are diagnosticians trying 
to figure out why something is going wrong.  Your audience is assumed 
to be familiar with the source code for the application and fully 
qualified class names make an effective hierarchy.  The logging 
requests are frequent and should be very low cost in normal operation.

Some other "audiences" would be security analysts, performance 
analysts, and business analysts.  Obviously one individual might be a 
diagnostician in one instance and a performance analyst in another, but 
thinking in terms of discrete audiences is helpful.  Logging requests  
intended for these other audiences are typically much less frequent, so 
the need to suppress "unnecessary" messages for performance reasons is 
much less important.

I would recommend using distinct Logger references for each of these 
audiences within the implementation.  For example:

public class Query {
     private static final Logger logger = Logger.getLogger(Query.class);
     private static final Logger performanceLogger = 
MyLoggerHelper.getPerformanceLogger(Query.class);
     private static final Logger securityLogger = 
MyLoggerHelper.getSecurityLogger(Query.class);
}

Your implementation of MyLoggerHelper.getPerformanceLogger could start 
out as simple as returning Logger.getLogger("performance") or 
Logger.getLogger("performance." + clz.getName());

One problem is when a message is of interest to multiple audiences.  
For example, the search metrics may be of interest to both the 
diagnostician and the performance analyst.  Since these would typically 
be low volume, it might be simplest just to repeat the message on both 
the diagnostic and performance logger.  Otherwise, you might be able to 
bridge loggers by routing "performance.com.example.foobar" to the same 
appenders as "com.example.foobar".