Mike,
Shouldn't be necessary to break into the source to do this. You can write an extension and use a combination of forwarding appenders, filters and level evaluators to get the same effect. Look in the extensions directory for the TraceAppender. You could easily add as many additional levels as you choose. The, the manner which you set up loggers, appenders, evaluators and filters in the configuration file, you can get the net effect of mutually exclusive logging 'levels' instead of hierarchal. In the extreme, you could use a separate logger for each level and rely on the logger name, not the level. Works fine, but then you lose the ability for type named loggers to help you find where the log message was generated. There is enormous flexibility in the log4net configuration files-just apply some creativity and experiment a bit. You might get what you want without a lot of coding. Ken Parrish Gomez, Inc. ________________________________ From: Mike Baker [mailto:[EMAIL PROTECTED] Sent: Thursday, February 07, 2008 4:38 PM To: Log4NET User Subject: RE: The current target framework (Microsoft .NET Framework 3.5) is not supported by log4net 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
