logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicko Cadell" <ni...@neoworks.com>
Subject RE: Wrapping LogManager to make ILog not rely on log4net.ILog
Date Mon, 16 May 2005 15:23:48 GMT

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



> -----Original Message-----
> From: Ron Grabowski [mailto:rongrabowski@yahoo.com] 
> Sent: 15 May 2005 20:55
> To: log4net-user@logging.apache.org
> 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
> 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

View raw message