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.


Reply via email to