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

________________________________

From: Daniel Marohn [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 07, 2008 12:15 PM
To: Log4NET User
Subject: Re: The current target framework (Microsoft .NET Framework 3.5)
is not supported by log4net

 

Hey Mike!

I do not see the point in building the sources. Are you coding against
the log4net sources? If you simply want to use log4net in your 3.5
projects, you can do it the way it do: Add a reference to the release
(or if you like the debug) log4net.dll, included inside the zip. Thats
it. 

Daniel

Reply via email to