> 1. In the ILog interface, log4net provides methods with open argument > lists > (DebugFormat etc.), but IIRC the params keyword of C# is not CLS > compliant. > What is your attitude towards CLS compliance? > (In our "old" logging infrastructure, we separated the members into > two > interfaces, ITracer and IClsTracer, with the second one containing > only CLS > compliant members. An idea would be to have two separate calls, > LogManager.GetLogger and LogManager.GetClsCompliantLogger, to get the > two > different interfaces.)
In this message: http://tinyurl.com/c6p94 http://www.mail-archive.com/log4net-user%40logging.apache.org/msg01678.html Nicko explains that there isn't anything particularly special about the ILog interface other than its the one that ships with log4net: " The ILog/LogManager classes are actually just an extension, the only difference between these and any 3rd party extension is they are included in the standard log4net distribution. " It sounds like designing and implementing your own interface (using ILog as a guide) might suit your needs better. Here is an example of an alternative interface and implementation: http://tinyurl.com/cssnd http://cvs.apache.org/viewcvs.cgi/logging-log4net/extensions/net/1.0/log4net.Ext.Trace/cs/src/ > 2. I've seen that you call String.Format relatively early, i.e. > before > calling Logger.Log(...) from the main logging methods (DebugFormat, > etc.) in > the LogImpl class. As String.Format can be time-consuming, > performance could > be improved by delaying this operation until after you call > IsEnabledFor in > Logger.Log (to avoid calling String.Format for messages that get > filtered > out by IsEnabledFor). Are you referring to this line of code: Logger.Log(ThisDeclaringType, m_levelDebug, String.Format(CultureInfo.InvariantCulture, format, args), null); (IsDebugEnabled) being better written like this: if (IsDebugEnabled) { Logger.Log(ThisDeclaringType, m_levelDebug, String.Format(CultureInfo.InvariantCulture, format, args), null); } This issue was fixed in March 2005: http://marc.theaimsgroup.com/?l=log4net-dev&m=111161599830698&w=2 > 4. Conditional overloads would be nice to have, e.g. FatalIf(bool > cond, > ...), that only generate the logging event if cond evaluates to true. Don't you think code like this would be difficult to maintain? log.FatalIf(temp, "Hello World"); Where is temp declared, is it passed in from another method, if it has been passed in has the user changed its value? > 5. As stated in > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/ht > ml/cpconmethodusageguidelines.asp, performance could be improved by > providing dedicated overloads for a small number of arguments, e.g. > DebugFormat(string format, object arg1, object arg2). If speed is an issue in your project you may need to look into certain optimizations that will be more applicatable for your project. Jaroslaw Kowalski, the author of NLog, states that log4net takes between 50-60 nanoseconds: 0.000000050 seconds to process a log instruction. For the majority of users, this amount of time is acceptable. - Ron
