Log4j 2
  1. Log4j 2
  2. LOG4J2-13

Appenders, layouts, etc should support deferred processing

    Details

    • Type: Wish Wish
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0-beta2
    • Component/s: None
    • Labels:
      None

      Description

      Appenders, Layouts and the like that interact with LoggingEvent should support deferred processing.

      This can be accomplished by having a distinct extract() method where the object constructs a value object containing the info needed for later processing from the LoggingEvent and other context (such as current thread, stack trace). At some later time, this value object may be rendered to complete the layout etc. This approach eliminates the need to preemptively collect information such as stack trace that may not be used or to clone the LoggingEvent to isolate the layout or appender from external changes.

        Activity

        Hide
        Scott Deboy added a comment -

        Related to layouts and LoggingEvent:

        In log4j 1.x, layouts were able to change the LoggingEvent fields (one example is if the appender's layout specified locationInformation). As a result, all following appenders contained this information, while appenders configured before this appender didn't contain locationInfo.

        We should avoid this side effect of a layout changing LoggingEvent state in Log4j 2.

        Show
        Scott Deboy added a comment - Related to layouts and LoggingEvent: In log4j 1.x, layouts were able to change the LoggingEvent fields (one example is if the appender's layout specified locationInformation). As a result, all following appenders contained this information, while appenders configured before this appender didn't contain locationInfo. We should avoid this side effect of a layout changing LoggingEvent state in Log4j 2.
        Hide
        Ralph Goers added a comment -

        LoggingEvents can be serialized and deserialized. AsynchAppender uses this to capture the logging event with all the information filled in to use on another thread. The logging event does not capture the stack trace, thread name, etc. until required. The logging event cannot be modified by the application once it is created. Attempts to update the ThreadContext Map and/or Stack in the logging event will result in an exception.

        Show
        Ralph Goers added a comment - LoggingEvents can be serialized and deserialized. AsynchAppender uses this to capture the logging event with all the information filled in to use on another thread. The logging event does not capture the stack trace, thread name, etc. until required. The logging event cannot be modified by the application once it is created. Attempts to update the ThreadContext Map and/or Stack in the logging event will result in an exception.

          People

          • Assignee:
            Ralph Goers
            Reporter:
            Curt Arnold
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development