Ron, If you want to develop your own custom adaptor around the log4net API then the best way to do this is to write an extension. By the sounds of it you have already done this, and this is still the right way to do it.
I am not sure how to implement this better at the moment given that the intention is to provide strongly types methods to looking up the logger wrapper objects. We may be able to use generics in cli 2.0 to leverage some code reuse in the LogManager/TraceLogManager. 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. There are examples of extensions in the download at extensions\net\1.0. The net\1.0 may be confusing, but it is used to indicate that the code is portable across all .net runtime platforms - actually this should probably be changed to cli\1.0 as that is more explicit, we would also have to update the examples in the same way. An extension does not have to extend the ILog interface, however it should extend the ILoggerWapper interface (the base of the ILog interface). User may expect you to support the standard ILog interface in your extension, but that depends on your application. Multiple extensions can be used side-by-side, therefore the calling app can still get an ILog implementation over the logger regardless of what other extensions are in use. In 1.2.9 changes were made to the LogImpl class to support rebinding levels in the config file at runtime. This is not the most obvious feature, but it is actually possible, although not advisable, to swap the DEBUG and ERROR levels at runtime. The ReloadLevels method was added to allow the LogImpl to keep up with any changes made to levels during configuration. The TraceLogImpl overrides the ReloadLevels method to add the TRACE level, while this is correct behaviour, it is not necessary if you don't intend to reconfigure your levels at runtime. If you need further clarification it may be helpful to briefly outline what does your custom extension does, or what custom APIs does it provides. Cheers, Nicko > -----Original Message----- > From: Ron Grabowski [mailto:[EMAIL PROTECTED] > Sent: 15 May 2005 20:55 > To: [email protected] > Subject: Wrapping LogManager to make ILog not rely on log4net.ILog > > Nicko, > > Several months ago I found a post on the SourceForge forums > that described how to abstract the log4net.ILog interface > into something like MyProject.Logging.ILog to allow a project > to change its logging implementation. You provided sample > code that looked something like > this: > > public class LogManager > { > private static readonly WrapperMap s_wrapperMap = new WrapperMap( > new WrapperCreationHandler(WrapperCreationHandler)); > > /* snip */ > > public static ILog GetLogger(string domain, string name) { > return WrapLogger(LoggerManager.GetLogger(domain, name)); } > public static ILog GetLogger(Assembly assembly, string name) > { return WrapLogger(LoggerManager.GetLogger(assembly, name)); > } > public static ILog GetLogger(Type type) { return > GetLogger(Assembly.GetCallingAssembly(), type.FullName); } > > /* snip */ > > There is much more code than that but does that give you an > idea of what I'm talking about? Do you a url for the post you > made? I can't seem to find it. > > Is there a better (more effecient?) way to implement that in > the new log4net 1.2.9 beta? I found these classes: > > http://tinyurl.com/cssnd > http://cvs.apache.org/viewcvs.cgi/logging-log4net/extensions/n et/1.0/log4net.Ext.Trace/cs/src/ > > I didn't know if that was the correct class to check my code > again. I saw methods like: > > protected override void > ReloadLevels(log4net.Repository.ILoggerRepository repository) > > that I don't have in my LogManager implementation and the > /net/1.0/ directory structure also caused some confusion. > > Thanks, > Ron >
