Log4net
  1. Log4net
  2. LOG4NET-259

Log4Net does not create a new tab in Chainsaw

    Details

    • Type: Task Task
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.2.10
    • Fix Version/s: 1.2.12
    • Component/s: Documentation
    • Labels:
      None

      Description

      I believe the problem is in XmlLayoutSchemaLog4j, and that you need to change "log4japp" to "application".

      According to the Chainsaw tutorial:
      Chainsaw automatically looks inside each received LoggingEvent for a special Application property to determine which tab to route an event to. If it cannot find this property, it attempts to use a secondary property usually added via the SocketAppender or SocketHubAppender which identify the remote host of these events. If neither of these are found, Chainsaw routes events to a default "Unknown" tab.

      Logging events generated internally by chainsaw include the following properties:
      <log4j:properties>
      <log4j:data name="application" value="Generator 1"/>
      <log4j:data name="hostname" value="localhost"/>
      <log4j:data name="log4jid" value="2"/>
      <log4j:data name="some string" value="some valueGenerator 1"/>
      </log4j:properties>

      Logging events generated by XmlLayoutSchemaLog4j include the following properties:
      <log4j:properties>
      <log4j:data name="log4net:UserName" value="DOMAIN\username"/>
      <log4j:data name="log4jid" value="281"/>
      <log4j:data name="log4jmachinename" value="machineName"/>
      <log4j:data name="log4net:HostName" value="machineName"/>
      <log4j:data name="log4japp" value="Application.exe"/>
      </log4j:properties>

      See also: http://www.mail-archive.com/log4j-dev@jakarta.apache.org/msg05361.html

      UPDATE: Documentation issue. See comments below.

        Activity

        Hide
        Scott Deboy added a comment -

        The tab routing mechanism is configurable, see application-wide preferences, general, 'tab identifier' field.

        You can provide any valid Chainsaw identifier or property name (or just a fixed string, if you want all events to go to the same tab)..

        The default value is:
        PROP.hostname - PROP.application

        But, you can change this to:
        PROP.log4net:HostName - PROP.log4japp

        (or log4jmachinename in the example above, since they appear to map to the same value)..

        Show
        Scott Deboy added a comment - The tab routing mechanism is configurable, see application-wide preferences, general, 'tab identifier' field. You can provide any valid Chainsaw identifier or property name (or just a fixed string, if you want all events to go to the same tab).. The default value is: PROP.hostname - PROP.application But, you can change this to: PROP.log4net:HostName - PROP.log4japp (or log4jmachinename in the example above, since they appear to map to the same value)..
        Hide
        David Mackersie added a comment -

        Changing the Chainsaw "tab identifier" field as described by Scott Deboy solves the issue.

        This would be worth mentioning in the "How To" at: http://logging.apache.org/log4net/release/howto/chainsaw.html

        Show
        David Mackersie added a comment - Changing the Chainsaw "tab identifier" field as described by Scott Deboy solves the issue. This would be worth mentioning in the "How To" at: http://logging.apache.org/log4net/release/howto/chainsaw.html
        Hide
        Scott Deboy added a comment -

        Generally I would prefer that the log4j-related appenders use a 'log4j' prefix for log4j-specific properties, so there is no collision with user-provided properties..

        That isn't the case currently for log4j's appenders, but this should be cleaned up..

        The task could be to make these properties consistent (in that case, the property names provided by log4net make sense, unless we want to add a dot (log4j.app, etc).

        Show
        Scott Deboy added a comment - Generally I would prefer that the log4j-related appenders use a 'log4j' prefix for log4j-specific properties, so there is no collision with user-provided properties.. That isn't the case currently for log4j's appenders, but this should be cleaned up.. The task could be to make these properties consistent (in that case, the property names provided by log4net make sense, unless we want to add a dot (log4j.app, etc).
        Hide
        Dominik Psenner added a comment -

        Fixed documentation as of revision: 1490207

        Show
        Dominik Psenner added a comment - Fixed documentation as of revision: 1490207

          People

          • Assignee:
            Dominik Psenner
            Reporter:
            David Mackersie
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development