logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Baker" <mike.ba...@harmonicinc.com>
Subject RE: The current target framework (Microsoft .NET Framework 3.5) is not supported by log4net
Date Thu, 07 Feb 2008 22:15:43 GMT
Thanks much for your help, Daniel and Ken.  Yes, if it wasn't apparent
already, I am a newbie to log4net.  I will look into the suggestions,
these sounds like much better (and easier) approaches to achieving what
we are trying to achieve with log4net.




From: Daniel Marohn [mailto:marohn@sipgate.de] 
Sent: Thursday, February 07, 2008 1:55 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:

Well, first: You can code your own filters, without toughing the log4net
code. You can simple add them with their fqdn in the config, and they
will be called when needed. Inherit from  log4net.Filter.FilterSkeleton
(no props with 3.5) . If you simple want to prevent the log to recieve
only one specified level, you can use the buildin filter
LevelMatchFilter (in your configfile). Possible that you did not know
about the filter in log4net? 

	LOG_FATAL:  Reserved for module-fatal unrecoverable conditions,
indicating the module cannot continue normal operations.  Normally never

	LOG_ERROR:  Reserved for module errors which are recoverable.
Normally never filtered.

	LOG_STATUS:  Catch-all, used to report status / information.

Defining custom loglevels is also easy without toughing then code. See
the trace example, provided with the sources


View raw message