Re: Extending Appenders

[Ralph Goers]

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  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  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  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 
>> 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  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 
>>> 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 
>>> 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 t

Re: Extending Appenders

[Michael Schall]

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  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  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 
> 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  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 
> > 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 
> > 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
> > > > wrote:
> > >
> > >> Looks like this class was made final in January 2013. The commit
> > message
> > >> m

Re: Extending Appenders

[Matt Sicker]

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  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  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  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 
> 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 
> 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 
> 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  > > 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
> > >
> >> wrote:
> >>
> >>> I'm upgrading an application to use Log4j2.  With our existing
> >>>

Re: Extending Appenders

[Jeff Shaw]

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

Re: Extending Appenders

[Gary Gregory]

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.

Gary

 Original message From: Remko Popma 
 Date:08/30/2014  03:19  (GMT-05:00) 
To: Log4J Users List  
Subject: Re: Extending Appenders 
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  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  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  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  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 >>> > 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:0

Re: Extending Appenders

[Remko Popma]

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

Re: Extending Appenders

[Michael Schall]

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

Re: Extending Appenders

[Ralph Goers]

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

Re: Extending Appenders

[Gary Gregory]

I would prefer to see changes that allows more flexible usage without
subclassing. If you subclass a core class, there is no guarantee that the
next release will be binary compatible. For the API, we do guarantee binary
compatibility within a major version.

Gary


On Fri, Aug 29, 2014 at 6:22 PM, Remko Popma  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  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  > > 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  > >
> > > 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
> > > >
> > >
> >
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Extending Appenders

[Remko Popma]

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

Re: Extending Appenders

[Michael Schall]

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

Re: Extending Appenders

[Remko Popma]

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

Extending Appenders

[Michael Schall]

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

Re: Extending Appenders

[Ralph Goers]

Did you import OutputStreamAppender, etc. and are log4j-api and log4j-core in 
the compile classpath?

The “StubManager” is where all the real i/o happens and will typically persist 
across a reconfiguration if the Appender is still being used. For an 
OutputStreamAppender it would probably extend OutputStreamManager.

You probably want to look at something like ConsoleAppender to see how a real 
Appender works.

Ralph

On Jul 14, 2014, at 10:54 AM, dxande6  wrote:

> I've tried extending the appenders with the following code and keep getting
> errors:
> 
> @Plugin(name = "Stub", category = "Core", elementType = "appender",
> printObject = true)
> 2.public final class StubAppender extends OutputStreamAppender {
> 3. 
> 4.private StubAppender(String name, Layout layout, Filter filter,
> StubManager manager,
> 5. boolean ignoreExceptions) {
> 6.}
> 7. 
> 8.@PluginFactory
> 9.public static StubAppender createAppender(@PluginAttribute("name")
> String name,
> 10. 
> @PluginAttribute("ignoreExceptions") boolean ignoreExceptions,
> 11.  @PluginElement("Layout")
> Layout layout,
> 12.  @PluginElement("Filters")
> Filter filter) {
> 13. 
> 14.if (name == null) {
> 15.LOGGER.error("No name provided for StubAppender");
> 16.return null;
> 17.}
> 18. 
> 19.StubManager manager = StubManager.getStubManager(name);
> 20.if (manager == null) {
> 21.return null;
> 22.}
> 23.if (layout == null) {
> 24.layout = PatternLayout.createDefaultLayout();
> 25.}
> 26.return new StubAppender(name, layout, filter, manager,
> ignoreExceptions);
> 27.}
> 28.}
> 
> I got this example from here:
> http://logging.apache.org/log4j/2.x/manual/extending.html
> 
> It tells me that OutputStreamAppender and LOGGER is not defined.
> I'm a little confused on what to do with this issue.
> 
> Additonally, I'm not familiar with StubManager and it's implementation, any
> insight is GREATLY appreciated.
> 
> Thank you,
> 
> -Dean
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-logging.6191.n7.nabble.com/Extending-Appenders-tp49160.html
> Sent from the Log4j - Users mailing list archive at Nabble.com.
> 
> -
> 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

Extending Appenders

[dxande6]

I've tried extending the appenders with the following code and keep getting
errors:

@Plugin(name = "Stub", category = "Core", elementType = "appender",
printObject = true)
2.public final class StubAppender extends OutputStreamAppender {
3. 
4.private StubAppender(String name, Layout layout, Filter filter,
StubManager manager,
5. boolean ignoreExceptions) {
6.}
7. 
8.@PluginFactory
9.public static StubAppender createAppender(@PluginAttribute("name")
String name,
10. 
@PluginAttribute("ignoreExceptions") boolean ignoreExceptions,
11.  @PluginElement("Layout")
Layout layout,
12.  @PluginElement("Filters")
Filter filter) {
13. 
14.if (name == null) {
15.LOGGER.error("No name provided for StubAppender");
16.return null;
17.}
18. 
19.StubManager manager = StubManager.getStubManager(name);
20.if (manager == null) {
21.return null;
22.}
23.if (layout == null) {
24.layout = PatternLayout.createDefaultLayout();
25.}
26.return new StubAppender(name, layout, filter, manager,
ignoreExceptions);
27.}
28.}

I got this example from here:
http://logging.apache.org/log4j/2.x/manual/extending.html

It tells me that OutputStreamAppender and LOGGER is not defined.
I'm a little confused on what to do with this issue.

Additonally, I'm not familiar with StubManager and it's implementation, any
insight is GREATLY appreciated.

Thank you,

-Dean




--
View this message in context: 
http://apache-logging.6191.n7.nabble.com/Extending-Appenders-tp49160.html
Sent from the Log4j - Users mailing list archive at Nabble.com.

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