Dynamically setting a log4net property using common.logging

Question

Does anyone know if there is an equivalent in Common.Logging (for .Net) to set properties for the log4net factory adapter? I have had great success when just using log4net by doing:

<appender name="FileAppender" type="log4net.Appender.RollingFileAppender">
    <file type="log4net.Util.PatternString" value="logs\Log_%property{BrokerID}.txt"/>
    <appendToFile value="false"/>
    <rollingStyle value="Size"/>
    <maxSizeRollBackups value="-1"/>
    <maximumFileSize value="50GB"/>
    <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%date %-5level %logger - %message%newline"/>
    </layout>
</appender>

and setting the property like:log4net.GlobalContext.Properties["BrokerID"] = 10

The file I end up with the looks like this: Log_(null).txt when using the common.logging to wire up log4net on the fly.

Answer 1

I don't think it makes sense to do this through common.logging, because common.logging is intended to provide a facade over the actual logging implementation so that you can switch between log4net, NLog, EntLib etc. without changing your application code (but just changing the configuration). Note that common.logging gives you a facade over loggers (ILog) but not over logging sinks (appenders in log4net parlance). So even if you could configure a BrokerID property, it's not clear how this might be used in the other logging backends.

Answer 2

See my answer to a previous question. Maybe it will help, maybe not.

To summarize:

1. Common.Logging (NET) says on its website that support for "context" is planned for the "next" release.

2. It is not clear on the website when the next release (the current release is 2.0) is scheduled. The website says "June". The current release (2.0) was April 2009. The website was last updated in May 2009 (maybe to announce 2.0)? What does "June" mean? June 2009? June 2010? Both have come and gone.

3. Given that "context" support is not available yet in Common.Logging, take a look at the "context" implementation in the Castle project (log4net implementation is here). It would not be hard to port that implementation to Common.Logging. A risk is that the context implementation that eventually comes from Common.Logging might not be similar to the Castle implementation.

4. The Castle "context" support is implemented on the ILog/ILogger interface. So, rather than setting the context like this:

Access to context via straight log4net:

log4net.GlobalContextProperties["BrokerID"] = 10;

Access to context via logging abstraction:

ILog logger = Common.Logging.LogManager.GetCurrentClassLogger();
logger.GlobalContextProperties["BrokerID"] = 10;

This seems pretty good from the perspective of setting the context when you have a logger. Maybe not so good if you just want to set the context without having gotten a logger. If the Common.Logging.LogManager knows what abstraction is "active" (and it should because the abstraction is settable/gettable via the LogManager.Adapter property). So, maybe the "context" could be available from the ILog interface as well as from the LogManager.Adapter interface.