What is the best pattern for using same Log4net logger across many assemblies in a solution?

Question

I have a solution consisting of a main winforms app, with associated internally written class library dll’s from which I wish to log. This logging should performed by the same logger, regardless of whether the main UI client or the associated dll’s call this. The dll’s may of course be used by other apps that have different loggers in other solutions, but in these circumstances will have a different log4net config and maybe a different suite of appenders altogether.

One approach would be to create a singleton within the main app and log from that, however since log4net is its own singleton, that can be referenced so as long as we pass the same string (or type) to log4net.LogManager.GetLogger we will be logging to the same destination (in my case I wish to use a RollingFileAppender).

This works. However, given that the DLL will have a number of classes it would mean each class instantiation or static class from which we wish to log would require i) an argument defining the logger name (in order to log to the same destination) and ii) at each entry point would need to call log4net.LogManager.GetLogger(loggerName).

What is the best pattern to use here? Would the correct approach be to create a singleton instance in each assembly? My concern here is that we will still need to pass in the logger name to each entry point for the dll, which seems like overkill. In order to avoid passing in the logger name, I might assume that it is always equal to System.Reflection.Assembly.GetCallingAssembly().GetName().Name.

If this is all too difficult for log4net, are there other easier solutions such as the Enterprise Logging Block? Or is the best solution an aspect oriented programming (AOP) approach?

Reference for anti-pattern approach for singleton here .

Answer 1

Almost one year later, but I thought I would contribute anyway!

Based on your comment to Carl's post, I think that maybe you misunderstand how log4net works. Yes, the loggername does identify the logger. Yes, a logger can have many appenders. BUT, many loggers can also write to the SAME appender. So, you could configure loggers "A", "B", and "C" to all log to file "X". You can get the loggers like this:

ILog logger_a = LogManager.GetLogger("A");
ILog logger_b = LogManager.GetLogger("B");
ILog logger_c = LogManager.GetLogger("C");

Now, if you log with any of these loggers, they CAN all go to the same place (file "X") if you configured them that way.

The advantage to NOT using the same logger name throughout your application is that you can control the level of logging in different places in your application via the config file. So, if the code that is using loggers "A" and "B" is working fine, but the code that is using logger "C" is having a problem, you could turn "A" and "B" off, and turn "C" all the way up. That way you have less information to have to dig through to find your problem.

Most people (or at least most log4net examples) actually create a static logger instance per CLASS, named for that class (I don't remember the exact syntax but it is easy to find examples). This gives you a very high level of granularity for controlling your logging.

In your app.config file, you can control all loggers at the same level by configuring a single logger called "*" or you can configure specific loggers (by using the fully qualified typename) or you can even configure by part of the fully qualified typename. For example, you could very easily make all classes in namespace ABC log at "info" level, all classes in namespace DEF log at "error" level, and all classes in namespace GHI not log at all. AND all of these loggers can log to the same destination (e.g file X).

Might have been too late to help, but maybe not...

Answer 2

First, you should create a wrapper class (to decouple your app from the logging provider).

This wrapper class could take the logger identifier. If you're using an IoC container, you could just inject the name of the logger, or an existing, pre-configured, instance.

If you're using Unity (other containers are similar), you could do something like

// During application initialization
IUnityContainer myContainer = new UnityContainer();
LoggingService concreteLoggingService = new LoggingService( "logID" );
myContainer.RegisterInstance<ILoggingService>( concreteLoggingService );

// This would be injected, so you wouldn't see this, but it's here for consistency
ILoggingService loggingService = myContainer.Resolve<ILoggingService>();
loggingService.LogMessage( "message" );

Now, this assumes you have an IoC container. You can alternatively create a service locator:

// During application initialization
ServiceLocator.Register<ILoggingService>( new LoggingService( "logID" ) );

// Retrieved as needed
ILoggingService loggingServce = LoggingServiceLocator.Locate<ILoggingService>();
loggingService.LogMessage( "message" );

In the second case you need to write all the plumbing code. With an IoC container, you get that out-of-the-box.