Log4net
  1. Log4net
  2. LOG4NET-31

Allow user to pass in additional parameters to <converter> node via some kind of <property> tag

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2.11
    • Component/s: None
    • Labels:
      None

      Description

      It would be useful if the user was able to supply additional properties to the <convert> tag in the form of:

      <property name="foo" value="bar" />
      <property name="Hello" value="World" />

      The code below uses a <property> node to determine if the HomeAddress or the WorkAddress will appear in the log message. If the parameter is not present, the converter prints a default value.

      <converter>
      <name value="user-converter" />
      <type value="Company.Project.Logging.UserConverter, Company.Project" />
      <property name="Address" value="HomeAddress" />
      </converter>
      <conversionPattern value="%p %d %user-converter

      {Nicko}

      - %m%n" />

      The <property> tags would be accessible via a Properties IDictionary. It would allow the converter to perform additional logic on the base.Option that was passed in:

      public class MyConverter : PatternConverter
      {
      override protected void Convert(TextWriter writer, object state)
      {
      User user = GetUserByUserName(base.Option);
      string address = base.Properties["Address"] as string;
      if (address != null && address.Length > 0)
      {
      if (user != null)
      {
      switch (address)

      { case "HomeAddress": writer.Write(user.HomeAddress); break; case "WorkAddress": writer.Write(user.WorkdAddress); break; }

      }
      else

      { // ??? }

      }
      else

      { // default display writer.Write(user.HomeAddress); break; }

      }
      }

        Issue Links

          Activity

          Hide
          Ron Grabowski added a comment -

          Fixed in r611621.

          Show
          Ron Grabowski added a comment - Fixed in r611621.
          Hide
          Ron Grabowski added a comment -

          I've implemented property support for PatternConverters so this syntax is supported:

          <converter>
          <name value="user-converter" />
          <type value="Company.Project.Logging.UserConverter, Company.Project" />
          <property>
          <key value="address" />
          <value value="HomeAddress" />
          </property>
          </converter>

          Its easy to add property support to other objects like Appenders but those are more well-defined than converters (think plugins) and explicit properties should be used.

          Show
          Ron Grabowski added a comment - I've implemented property support for PatternConverters so this syntax is supported: <converter> <name value="user-converter" /> <type value="Company.Project.Logging.UserConverter, Company.Project" /> <property> <key value="address" /> <value value="HomeAddress" /> </property> </converter> Its easy to add property support to other objects like Appenders but those are more well-defined than converters (think plugins) and explicit properties should be used.
          Hide
          Nicko Cadell added a comment -

          The 'log4net:ERROR XmlHierarchyConfigurator: Cannot find Property [address] to set object on [log4net.Layout.PatternLayout+ConverterInfo]' error is expected because the XmlHierarchyConfigurator uses reflection to set the values of properties on objects using the XML as a source.

          There are a couple of ways of achieving your example with the current implementation. First you could write 2 converters, one for the HomeAddress and one for the WorkAddress, then select which one to use in the config file. Alternatively you could write 1 converter which parses the Home/Work tag from the start of the Option string, i.e. you would write in the pattern %user-converter

          {Home:Ron}

          . The converter could split the Option string on the colon to decide what to do.

          These workarounds are not as generalised as what you are suggesting.

          Show
          Nicko Cadell added a comment - The 'log4net:ERROR XmlHierarchyConfigurator: Cannot find Property [address] to set object on [log4net.Layout.PatternLayout+ConverterInfo] ' error is expected because the XmlHierarchyConfigurator uses reflection to set the values of properties on objects using the XML as a source. There are a couple of ways of achieving your example with the current implementation. First you could write 2 converters, one for the HomeAddress and one for the WorkAddress, then select which one to use in the config file. Alternatively you could write 1 converter which parses the Home/Work tag from the start of the Option string, i.e. you would write in the pattern %user-converter {Home:Ron} . The converter could split the Option string on the colon to decide what to do. These workarounds are not as generalised as what you are suggesting.
          Hide
          Ron Grabowski added a comment -

          When I try this snytax:

          <converter>
          <name value="user-converter" />
          <type value="Company.Project.Logging.UserConverter, Company.Project" />
          <address value="HomeAddress" />
          </converter>

          I get the following error:

          log4net:ERROR XmlHierarchyConfigurator: Cannot find Property [address] to set object on [log4net.Layout.PatternLayout+ConverterInfo]

          Show
          Ron Grabowski added a comment - When I try this snytax: <converter> <name value="user-converter" /> <type value="Company.Project.Logging.UserConverter, Company.Project" /> <address value="HomeAddress" /> </converter> I get the following error: log4net:ERROR XmlHierarchyConfigurator: Cannot find Property [address] to set object on [log4net.Layout.PatternLayout+ConverterInfo]

            People

            • Assignee:
              Ron Grabowski
              Reporter:
              Ron Grabowski
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development