You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Curt Arnold (JIRA)" <ji...@apache.org> on 2008/06/19 23:59:45 UTC
[jira] Created: (LOG4J2-13) Appenders, layouts, etc should support
deferred processing
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[jira] Commented: (LOG4J2-13) Appenders, layouts, etc should
support deferred processing
Posted by "Scott Deboy (JIRA)" <ji...@apache.org>.
[ 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org