I'd be happy to help. But given the fact that I'm a Microsoft employee with some strict open source restrictions, I can only provide support for it.
In short, if log4net stores its logical call-tracking context stack using CallContext.LogicalSetData and retrieves it using the similarly named method, everything should automatically work. If not, I can hopefully provide additional help. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Mon, Nov 28, 2011 at 9:13 PM, Stefan Bodewig <bode...@apache.org> wrote: > On 2011-11-28, Andrew Arnott wrote: > > > The documentation is poor, I agree. I had to stumble around quite a bit > > before I figured out how to use it properly myself. I believe the > > difference may be that CallContext.*Logical*SetData requires the value to > > be serializable, so that it can be cloned and applied to other threads, > > perhaps even in separate appdomains. > > > This sounds like an area that log4net can improve then. > > For .NET 2+, yes. > > > I'm not sure why log4net claims to follow the logical thread when > > apparently it doesn't. > > It probably does in some circumstances but obviously not all of them. > > > The good news is that in the absence of built-in support from log4net, > I've > > engineered a solution of my own by controlling the > > HostExecutionContextManager in my AppDomain. Whenever the logical thread > > forks (i.e. threadpool use, c# 5 async keyword, etc.) my code "captures" > > the current context stack from log4net and applies that stack to the new > > thread, and "reverts" that change when the target thread has completed > its > > work for that call. > > > Pretty cool stuff, but it would be cooler if log4net had it built-in. > > Oh, feel free to help log4net improve here 8-) > > Cheers > > Stefan >
