Dictionary property reader

Oct 4, 2010 at 2:38 PM

How difficult would it be to implement a property reader that could read a value from a dictionary, similar to the GDC/MDC objects in log4net and NLog?  Let's say that I have a static dictionary called GlobalDiagnosticContext (like log4net and NLog).  In either of those libraries I could have something like this in my format string:  ${gdc:item=name}.  In NLog that would pull the value from the static variable GDC with the key "name".  I guess the question is can we pass a parameter to a PropertyReader that would be the dictionary key value?  The property reader architecture does not necessarily have to be dictionary aware.  Rather, it could provide for a parameterized token to specified in the app.config file.  Maybe it is easier to assume a dictionary-style access and provide a token specification syntax that explicitly supports that.

Something like:

{MyCustomToken[tokenParameter]} //MyCustomToken is a custom token that expects to have access to the string in the [ ] brackets.

 

A simplistic implementation of such a reader itself might look something like this:

  public class DictionaryPropertyReader : AbstractDictionaryPropertyReader
  {
    public override bool TryGetValue(out object value, TraceEventCache cache, string source,
                                     TraceEventType eventType, int id, string formatOrMessage, object[] data)
    {
      if (_key != null && _key.Length > 0)
      {
        if (MyStaticDictionary.TryGetValue(_key, out value))
        {
          return true;
        }
        else
        {
          return false;
        }
      }
    }
  }

//Alternatively, one of the objects in data could have the dictionary.
  public class DictionaryPropertyReader : AbstractDictionaryPropertyReader
  {
    public override bool TryGetValue(out object value, TraceEventCache cache, string source,
                                     TraceEventType eventType, int id, string formatOrMessage, object[] data)
    {
      MyLogEntry le = data[0] as MyLogEntry;
      if (le == null)
      {
        return false;
      }

      if (_key != null && _key.Length > 0)
      {
   
        if (le.Properties.TryGetValue(_key, out value))
        {
          return true;
        }
        else
        {
          return false;
        }
      }
    }
  }

//Alternatively, one of the objects in data could BE the dictionary

 

Where AbstractDictionaryPropertyReader could be a Ukadc.Diagnostics-provided base class that, as part of the app.config parsing/PropertyReader creation logic would have its "_key" property set.  Inheritors could then use the TryGetValue function plus the _key value to access their dictionary (wherever it might be), or do anything else with the parameter that they might want to.

With this, if someone were inclined to store some properties in a dictionary to mimic log4net and NLog functionality, they could write a PropertyReader to get the values.

This is not something that is particularly critical for me (at least right now) as we are leaning towards going with log4net or NLog (via Common.Logging) right now, but I am also trying to keep our options open.  To that end, I do have a TraceSource-based logger that I can put behind the Common.Logging facade, so I could still take advantage of Ukadc.Diagnostics.

Anyway, that was just a thought.