Re: log4net Contexts and ASP.NET
Josh, I've been doing something similar with remoting Contexts. I'm putting some objects into a new Context, and using ContextProperties to inject message sinks which intercept some calls and add information to the Context Property. In this case i'm not using the ThreadLogicalContext as i want these properties to be present at all times in the object on all threads, and dont want to have to add them for each call (as is my understanding with the CallContext used by ThreadLogicalContext) To get the property values into log messages I've created a type that in its ToString() gets a specified ContextProperty and returns it's ToString(). Then I add as many of these to the GlobalContext as i need, following the Active Property Values pattern here http://logging.apache.org/log4net/release/manual/contexts.html Perhaps you could create something similar (add objects to the GlobalContext) to read values from the HTTPContext as a work around. aaron josh robb 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.
Re: log4net Contexts and ASP.NET
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?)
Re: log4net Contexts and ASP.NET
On 2/16/06, josh robb [EMAIL PROTECTED] wrote:
Conceptually - this is what I'm proposing:if(isWeb and HttpContent.Current != null){ // store context in HttpContext.Current.Items} else { // sore it in CallContext.}
Josh, why bother with a flag called isWeb? If HttpContext.Current is
not null then you know you are in the context of a web app; otherwise
you aren't. It works great just checking the HTTP context because then the same code can execute in a web app or a non-web app.
I too don't see any issues with log4net referencing System.Web either,
or System.Remoting for that matter if it has anything needed in it for
this functionality.-- -glenn-
