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: http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html "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 asp.net 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. } j. (Peirs - are you on this list?)
