Re: [Netcommon-developer] Common.Logging and logging contexts

[Geoghegan, W. A (Willie) <wil...@in...>]

Erich,

 

Thanks.  I understand about being busy.  Feel free to contact me directly or via the netcommon list if you have any questions about what I have posted.  I don’t know if there is any way that I can contribute, but I could certainly send you some work that I have done and you could decide for yourself if it looks useful or not.

 

Thanks again.

 

Willie.

 

From: Erich Eichinger [mailto:eei...@gm...] 
Sent: Monday, October 11, 2010 8:45 AM
To: 'Kenneth Xu'; Geoghegan, William A (Willie)
Cc: net...@li...
Subject: Re: [Netcommon-developer] Common.Logging and logging contexts

 

Hi folks,

 

yes, I am. Unfortunately I am quite busy atm, I will come back to you as soon as possible, probably next week.

 

Thanks a lot Will for your effort, highly appreciated. Next week I hopefully have time to carefully read you posts and comment on them. Please be patient ;-)

 

cheers,

Erich

 

From: ken...@gm... [mailto:ken...@gm...] On Behalf Of Kenneth Xu
Sent: 11 October 2010 14:41
To: Geoghegan, William A (Willie); Erich Eichinger
Cc: net...@li...
Subject: Re: [Netcommon-developer] Common.Logging and logging contexts

 

William, I'm forwarding to Erich directly to see if he is still maintaining the project.

On Fri, Oct 1, 2010 at 5:47 PM, Geoghegan, William A (Willie) <wil...@in...> wrote:

Too long again.  Part 1.

I have seen on the Common.Logging home page that Logging Context support is planned for the next release.  In the meantime, I have implemented a logging context abstraction that is based, in part, on Castle’s logging context abstraction that they provide for log4net and NLog.  At this point I consider it somewhat experimental, but I think there are some ok ideas here.  I also did not modify any Common.Logging code.  In a “real” implementation, I would expect that context would be available from LogManager (or maybe from ILog as was done in Castle).  I think that making it available from ILog could be misleading because it could be read as “the logging context for THIS logger”, which is not really true.

Anyway, with my code you can do something like to this to set the context (LogContext is my static object that provides the entry point into the logging context abstraction):

LogContext.GlobalProperties[“number”] = 1234;

LogContext.ThreadProperties[“id”] = System.Threading.Whatever.Id;

using (LogContext.ThreadStack.Push[“outer level”])

{

  DoSomeStuff();

  

  using (LogContext.ThreadStack.Push[“inner level”)

  {

    DoSomeStuffFromInnerLevel();

  }

}

Which logging context abstraction is in play is dictated by the current LogManager.Adapter’s implementation (or lack of same) of an interface, IContextProvider.  When one of the context operations (GlobalProperties, ThreadProperties, ThreadStack) is access on LogContext, code like this executes:

IContextProperties GlobalProperties

{

  get

  {

    IAdapterContextProvider iacp = LogManager.Adapter as IContextProvider;

    if (iacp == null)

    {

      return NullContextProvider.GlobalProperties; //Does nothing, but also does not fail.

    }

    else

    {

      return iacp.Context.GlobalProperties; //Global properties relevant to the currently abstracted logger

    }

  }

}

To take advantage of LogContext, I have copied the NLog abstraction provided by Common.Logging and added the IAdapterContextProvider interface.  Now, when I configure my NLog abstraction, LogContext finds that LogManager.Adapter does support the interface, so the NLog context values can be set.  I have done something similar for log4net.

William A. Geoghegan
Software Scientist
Intergraph Corporation
Security, Government & Infrastructure (SG&I) Division
P.O. Box 6695, Huntsville, AL 35824-0695 USA
P 1.256.730.8371
wil...@in..., www.intergraph.com 


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Netcommon-developer mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/netcommon-developer