[ 
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]

Reply via email to