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.
> 

Reply via email to