logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: Extending Appenders
Date Tue, 02 Sep 2014 16:24:46 GMT
After looking at SmtpAppender, SmtpManager and your eamil it doesn’t sound to me like there
is a lot of benefit in extending SmtpAppender or SmtpManager. Their primary purpose of those,
and the majority of the code, is to send email - which you have said your version doesn’t
do. The only code you seem to want to reuse is the isFiltered method in the Appender and the
CyclicBuffer in the Manager which together is a very small amount of code.

If there is some refactoring here that should happen to make what you want easier perhaps
that should be considered.

Ralph

On Sep 2, 2014, at 9:08 AM, Michael Schall <mike.schall@gmail.com> wrote:

> Thanks for all your input.
> 
> I'm going to try and implement the appender we need to maintain our current
> throttling infrastructure.  I will send a patch with the changes we need as
> far as moving items from private to protected and removing the final
> keyword.
> 
> 
> On Sat, Aug 30, 2014 at 2:02 PM, Matt Sicker <boards@gmail.com> wrote:
> 
>> http://logging.apache.org/log4j/2.x/manual/filters.html#BurstFilter
>> http://logging.apache.org/log4j/2.x/manual/appenders.html#RoutingAppender
>> 
>> There are several ways to go about implementing what you're asking about
>> using existing features. You may be able to get what you need by using just
>> the burst filter and routing appender (which itself may not be required
>> depending on your usage).
>> 
>> 
>> On 30 August 2014 09:27, Jeff Shaw <jeff@bitgladiator.com> wrote:
>> 
>>> 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.popma@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.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>
>>> 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.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 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.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?  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-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
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>> 
>>> 
>> 
>> 
>> --
>> Matt Sicker <boards@gmail.com>
>> 


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


Mime
View raw message