[
https://issues.apache.org/jira/browse/LOG4J2-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13539307#comment-13539307
]
Ralph Goers commented on LOG4J2-131:
------------------------------------
The issue with the Filter is a good point. At the same time, if two
LoggerContext's are sharing the same configuration you would end up two buffers
each containing only some of the events. This can occur if you have a parent
and a child ClassLoader (such as in Tomcat) and the Log4j jars are in Tomcat's
directories, not the web apps. In that case, when an error occurs you would get
an email but it would be missing either all the log entries from classes in
Tomcat's ClassLoader or all the log entries from the web app ClassLoader. With
a single manager they are all combined and you would get what I think is the
expected behavior.
A similar problem occurs in the RollingFileAppender. In that case, once the
manager has been created for a single file subsequent appenders will use it and
whatever they specify for a policy or strategy will be ignored (to do otherwise
would cause quite a mess).
In this case I would think the String value of the Filter, along with many of
the Appender parameters, would become part of the manager's "name". Since it
will be pretty long I'd probably use an MD5 like the Flume Embedded Appender
does.
> Create SMTPAppender
> -------------------
>
> Key: LOG4J2-131
> URL: https://issues.apache.org/jira/browse/LOG4J2-131
> Project: Log4j 2
> Issue Type: New Feature
> Components: Appenders
> Reporter: Christian Grobmeier
> Attachments: SMTPAppender.patch
>
>
> Somebody in twitterverse reverted back to log4j 1.2 because he missed the
> SMTP Appender
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]