logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Extending Appenders
Date Sat, 30 Aug 2014 13:05:38 GMT
This sounds like something JMS could help with using messages in a queue instead of watching
files in a folder. Maybe that part can pluggable: JMS vs. a folder.


<div>-------- Original message --------</div><div>From: Remko Popma <remko.popma@gmail.com>
</div><div>Date:08/30/2014  03:19  (GMT-05:00) </div><div>To: Log4J
Users List <log4j-user@logging.apache.org> </div><div>Subject: Re: Extending
Appenders </div><div>
</div>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.schall@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.goers@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.popma@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.schall@gmail.com>
>>>> 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.popma@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
>>>>> 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.schall@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?
>>>>> 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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message