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.
