Ron Grabowski <[EMAIL PROTECTED]> wrote:
> I don't think HttpContext is always available...especially inside the
> Global.asax.cs methods and/or inside CacheItemRemovedCallback methods.

HttpContext is available during the life cycle of a Http request. This
includes any event handler in Global.asax which is associated with
Request handling. (The only one off the top of my head where this is
not the case would be Session_End - which has it's own problems).

> HttpContext is just a wrapper around
> System.Runtime.Remoting.Messaging.CallContext. Log4Net doesn't have a
> reference any of the Remoting libraries.

HttpContext uses CallContext but it is not _just_ a wrapper. Peirs
outlines this very clearly in an execlent post:

"Under load ASP.Net can migrate inbound requests from its IO thread
pool to a queue taken up by it's worker process thread pool"

Under 2 - this appears to happen as a matter of course (due to
the async processing support?). This means that Context info will be
leaked between requests. (Which shouldn't happen).

I don't understand the relevance of your comment about references to
Remoting. (log4net already references System.Web).

> If you know that HttpContext is a better place to store thread specific
> information, you could do this:

HttpContext is the _only_ safe place to store information related to
one HttpRequest. (e.g. currently authenticated user, Requested Url
etc....) This is because ASP.NET can (and does) migrate HttpRequests
between threads during the processing of a single request.

> 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();

I'm happy to write whatever is required (a custom MDC or formatter or
whatever) but there should be 1 documented and supported solution for
log4net which supports logging contexts running under ASP.NET.

In my opinion - this should involve changing the ThreadLogicalContext
so that it can be used in the business layer. I mentioned adding a
configuration option to enable using HttpContent. I should have added
that even if that option is enabled then HttpContext would need to be
checked and if it is unavailable then CallContext should be used as it
is currently. (If HttpContext.Current is null - then CallContext is
the right place for context info as it's the HtppRequest processing
infrastructure that does the thread migration anyway).

Conceptually - this is what I'm proposing:

if(isWeb and HttpContent.Current != null)  {
   // store context in HttpContext.Current.Items
} else {
   // sore it in CallContext.


(Peirs - are you on this list?)

Reply via email to