It's not a bug per-se, but I think it's definitely worth putting
something up onto
http://logging.apache.org/log4net/release/manual/contexts.html
regarding how ThreadContext and LogicalThreadContext are both
completely unsuitable for use within ASP.Net.
Otherwise naive developers (myself previously included) might
accidentally do something like set the ThreadContext up in the
Application_BeginRequest event, and wonder why things are being logged
against the wrong context under load.
(For anyone who's still blissfully unaware of this particular gotcha,
ASP.Net can switch threads during a request's lifetime, and the *only*
thing that goes to the new thread is the HttpContext. More light
reading:
http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html
)
Personally I'd like to see log4net have an 'AdaptiveContext' / 'UserContext' that
implemented a context store in HttpContext if available, or CallContext
else (so log4net callers in business layers don't have to know anything
about what environment they're running in), but I'm content with my
'fill GlobalContext with provider objects' workaround for now, I just
want to spare others the pain.
--
piers, senior developer, UnisysWest
http://piers7.blogspot.com/
