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 <[EMAIL PROTECTED]> 01/19/2005 05:38 PM Please respond to "Log4CXX User" To: Log4J Users List cc: Log4CXX User 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 [EMAIL PROTECTED] 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".
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 [EMAIL PROTECTED] 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".
Advice requested on best way to implement log4* to support non-hierarchal categories
My company is looking to standardize our logging across all of our C++ (and eventually Java) projects and we would certainly rather use a well-known architecture such as log4j/log4cxx rather than growing our own. My biggest challenge is that one of the key desires our developers have is to be able to mix and match the selectiveness of the logging. The easiest way to explain would probably be by example. We would like to be able to easily mix and match any of the following categories of log messages: * performance/timing related * search result related * search result quality related * any messages in the hierarchy com.foo * no messages from the class/hierarchy com.foo.bar We were hoping to be able to define the characteristics of log messages within the class com.foo.bar so that we could have overall performance log messages, search result performance messages, search result quality messages, overall search result messages, etc. and then via configuration we could say, "hrm, lets take a look at the search result quality across all of com.foo. Is anyone else doing anything like this out there? I have done quite a bit of reading on the log4j and log4cxx documentation, but I have not found a good resource for explaining the Filter class hierarchy. Any pointers or advice is welcome. Thanks, Daniel E.