It sounds like a feature that belongs to any logger. Syslog doesn't need to know that a database server is unavailable every nanosecond, either.
Sent from my phone > On Aug 30, 2014, at 3:19 AM, Remko Popma <remko.po...@gmail.com> wrote: > > This sounds like a good feature to have in log4j2. I remember we had an issue > at work where error logs were emailed automatically, bringing down the mail > server when the app kept generating the same error. Painful. > > Sent from my iPhone > >> On 2014/08/30, at 7:24, Michael Schall <mike.sch...@gmail.com> wrote: >> >> Again, thanks for all the interest in my request. >> >> I don't have the code in front of me, but I will try and give an >> overview of what we did for log4j 1.x. >> >> We want to send emails for errors happening in production. However for >> example, we don't want to send thousands of emails if the network goes >> down to a database. If we have an issue that attempts to send more >> than X emails in a timeframe, we want to only send 1 email at high >> priority and "archive" the rest. If the issue is not resolved we may >> send multiple high priority emails until the issue is resolved, but >> only a fraction of the emails are actually sent. >> >> We have a standalone service that does all the throttling logic by >> watching a folder for file creations. So the appender I'm talking >> about writing doesn't actually send emails. It just does everything >> the SmtpAppender does (buffering, evaluating, ...), but writes a file >> to a "watch" folder instead of sending messages. The service then >> either sends the mail or throttles and sends at high priority. >> >> So, my thought is that I would extend the SmtpAppender and override >> the sendEvents method to write out the contents of the buffer to a >> file. This approach has worked great with log4j 1.x. >> >> Mike >> >>> On Aug 29, 2014, at 11:28 PM, Ralph Goers <ralph.go...@dslextreme.com> >>> wrote: >>> >>> This is a fair point. There are some things not in the API that we >>> wouldn’t change as they would also break compatibility, such as the Layout >>> or Appender interface, but we aren’t guaranteeing that specific Appender or >>> Layout instances won’t have a new parameter added to them or things like >>> that. >>> >>> Ralph >>> >>>> On Aug 29, 2014, at 3:22 PM, Remko Popma <remko.po...@gmail.com> wrote: >>>> >>>> I would not object to changing SmtpAppender to make it more extendible. >>>> >>>> Can you tell me more about your use case? SmtpAppender is designed this way >>>> because we had a specific usage in mind. By understanding your use case we >>>> might be able to improve the design in a way that benefits not just you but >>>> other users as well. What do you want to do that you can't do with the >>>> current SmtpAppender? >>>> >>>> Looks like several changes are required. I am away from my PC and can't >>>> judge the details now. Could you raise a feature request Jira and attach a >>>> patch that includes all the changes you'd like to make? That might save us >>>> some going back and forth. >>>> >>>> Thanks! >>>> Remko >>>> >>>>> On Friday, August 29, 2014, Michael Schall <mike.sch...@gmail.com> wrote: >>>>> >>>>> Thanks for your response Remko. >>>>> >>>>> Looking into this further, I could duplicate the SmtpAppender code as it >>>>> really just seems to do plugin work. The bulk of the code is in the >>>>> SmtpManager class which is not marked final. The constructor is marked >>>>> protected, however it takes a private class (FactoryData). I would also >>>>> like to override the sendEvents method, but then I run into issues because >>>>> the buffer is private. >>>>> >>>>> Do these changes seem like an issue? >>>>> >>>>> Mike >>>>> >>>>> >>>>> On Fri, Aug 29, 2014 at 4:51 PM, Remko Popma <remko.po...@gmail.com >>>>> <javascript:;>> wrote: >>>>> >>>>>> Looks like this class was made final in January 2013. The commit message >>>>>> mentions checkstyle errors. >>>>>> What change are you proposing? Would just removing the final keyword from >>>>>> the class definition be enough to fulfill your needs? >>>>>> >>>>>> It may be good to raise this as a feature request in Jira. >>>>>> If you need more changes than just making the class non-final, please >>>>>> attach a patch with the changes you have in mind. >>>>>> >>>>>> >>>>>> On Sat, Aug 30, 2014 at 4:07 AM, Michael Schall <mike.sch...@gmail.com >>>>> <javascript:;>> >>>>>> wrote: >>>>>> >>>>>>> I'm upgrading an application to use Log4j2. With our existing >>>>>>> implementation we have created a new appender which extends the >>>>>>> SMTPAppender. I see the SMTPAppender is a final class now which >>>>> prevents >>>>>>> me from extending it. I was wondering what the reason for this is? Do >>>>>> we >>>>>>> really need to re-implement the the entire SMTPAppender (properties, >>>>>>> buffering, ...) to extend the appender? >>>>>>> >>>>>>> Thanks for your time. >>>>>>> >>>>>>> Mike >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >> For additional commands, e-mail: log4j-user-h...@logging.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
