[
https://issues.apache.org/jira/browse/LOG4J2-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607135#action_12607135
]
Scott Deboy commented on LOG4J2-13:
-----------------------------------
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.
> Appenders, layouts, etc should support deferred processing
> ----------------------------------------------------------
>
> Key: LOG4J2-13
> URL: https://issues.apache.org/jira/browse/LOG4J2-13
> Project: Log4j 2
> Issue Type: Wish
> Reporter: Curt Arnold
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
