I don't think HttpContext is always available...especially inside the Global.asax.cs methods and/or inside CacheItemRemovedCallback methods.
According to this article: http://www.odetocode.com/Articles/112.aspx HttpContext is just a wrapper around System.Runtime.Remoting.Messaging.CallContext. Log4Net doesn't have a reference any of the Remoting libraries. If you know that HttpContext is a better place to store thread specific information, you could do this: <layout type="log4net.Layout.PatternLayout"> <converter> <name value="httpContextMdc" /> <type value="Company.Logging.HttpContextMdc" /> </converter> <conversionPattern value="%message %httpContextMdc{NAME}%newline" /> </layout> Or maybe even override the %X, %MDC, etc. to look in HttpContext by writing your own PatternLayout: <layout type="Company.Logging.HttpContextMdcPatternLayout"> <conversionPattern value="%message %X{NAME}%newline" /> </layout> Making your business layer call through to your own static methods for storing items in the MDC would put you in a good position if anything changes later on: Company.Logging.ThreadContext.Properties["NAME"] = getUserName(); --- josh robb <[EMAIL PROTECTED]> wrote: > I've seen an email from Piers Williams in december asking about this. > > Basically - in an ASP.NET application - none of the existing contexts > are "safe" to use. > > I'd like to remedy this. There are two ways forward that I can see. > > 1. Add a new WebContext class. > 2. Change the ThreadLogicalContext class to use the HttpContext if > required. The safest way to do this would be to add a configuration > option to <log4net isWeb="true"> and test for this in > ThreadLogicalContext. > > I (probably) prefer 2 because it means your Business layer does not > need to be aware of whether or not it is running in a web context. > > Has anyone got any thoughts on this or done any work here already? > > j. >