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 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, Aaron Morton <[EMAIL PROTECTED]> wrote: > Perhaps you could create something similar (add objects to the > GlobalContext) to read values from the HTTPContext as a work around. Nice - Ok - for the two things I've mentioned so far (User Identity and Requested Url) this would be a fine solution. This allows us to safely capture state about a request. However for business layer logging - where the context is dependant on the actual action performed this does not sound like it would work well. (i.e. the contextual information is dependant on the actual sequence of actions performed with a single request). Thanks for the useful ideas! (They solve my immediate problems). However I still have several problems: 1. ThreadLogicalContext is demonstrably not safe for use in a ASP.NET environment. (Not just in pages but in any components used by those pages). 2. This is not documented or mentioned anywhere. 3. There is no log4net support/recommended alternative (or pattern/best practice). j.
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-
Re: log4net Contexts and ASP.NET
On 2/16/06, GlennDoten <[EMAIL PROTECTED]> wrote: > 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. Thanks for the feedback - I initially thought of this - but I thought it made sense to keep the new behaviour optional. (It's possible to imagine circumstances where you'd rather use the CallContext even if you're in the middle of a web request). Are we getting close to agreement about what the patch should look like? If so I can knock something together - to hopefully generate some more discussion. j.
