logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: The current target framework (Microsoft .NET Framework 3.5) is not supported by log4net
Date Fri, 08 Feb 2008 00:04:31 GMT

On Feb 7, 2008, at 3:38 PM, Mike Baker wrote:

> The reason for getting into the source is we are interested in  
> changing the way log filtering is done.  Rather than having levels  
> of fatal, error, info, warn, debug, etc., which are hierarchically  
> enabled (i.e., if you set the level for debug, you get all the  
> rest), we would like to be able to selectively enable different  
> logging by log category/type, for example:
> LOG_FATAL:  Reserved for module-fatal unrecoverable conditions,  
> indicating the module cannot continue normal operations.  Normally  
> never filtered.
> LOG_ERROR:  Reserved for module errors which are recoverable.   
> Normally never filtered.
> LOG_STATUS:  Catch-all, used to report status / information.
> LOG_CONFIG:  Used to report configuration change activities.
> LOG_FUNC:  Used to report entry / exit from functions.
> LOG_TIMING:  Used to report performance, i.e., the module has  
> reached an observable event.
> LOG_COMM:  Used to report the module is attempting / has completed  
> intermodule communications.
> LOG_DBA:  Used to report database activities.
> LOG_USER08…LOG_USER31:  TBD usage, perhaps to accomplish special  
> debug logging / filtering for troubleshooting a system problem.
>
> We would like these log messages from these various categories/types  
> to be enabled / disabled independently.  For example, if we are  
> trying to optimize performance, we might only turn on LOG_TIMING to  
> try identify what is running slow.  Profiling helps on this, but if  
> a call varies significantly in how long it takes depending upon the  
> parameters passed, logging will help us focus on the problem.
>
> In a previous company that I worked, there was a C++ logging library  
> that supported both logging priority (hi, med, low – analogous to  
> log4net’s fatal, error, etc.), but also included logging category,  
> like described above.  We found was that logging category was quite  
> useful in actual debugging, and having the logging priority, even  
> though there were 3 levels, we essentially used them more like  
> boolean flags.
>
> Has anyone else considered something similar to what I described  
> above for log4net?
>
> Thanks,
> -Mike


It is a pretty common temptation to want to use levels to indicate  
topic or audience which is precisely what the logger name hierarchy  
(which was originally called category in log4j, but was renamed as  
logger to be consistent with JDK 1.4's logging)  is intended to do.   
Most new users wrongly assume that logger names MUST mirror class  
names.  That is one useful pattern, but not the only pattern for  
organizing your logging messages,

If you attempt to use level to indicate topic, then you come up with  
the dilemma on how to prioritize highly significant TIMING or COM or  
DBA messages from less significant messages.

I would suggest that you use logger names like:

"com.example.myapp.myclass" for generic diagnostic logging
"dba.com.example.myapp.myclass" for database relative logging in that  
specific class.
"comm.com.example.myapp.myclass" for communication relative logging in  
that specific class.
"timing.com.example.myapp.myclass" for timing relative logging in that  
specific class.

You could flip the order if the class is a more significant than  
function for filtering or routing.



Mime
View raw message