You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Michael Schall <mi...@gmail.com> on 2014/09/02 18:08:45 UTC
Re: Extending Appenders
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 <bo...@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 <je...@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 <re...@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 <mi...@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 <re...@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 <mi...@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 <bo...@gmail.com>
>
Re: Extending Appenders
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <mi...@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 <bo...@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 <je...@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 <re...@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 <mi...@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 <re...@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 <mi...@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 <bo...@gmail.com>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org