Mailing-List: contact log4j-user-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Users List" <log4j-user@logging.apache.org>
Received-SPF: pass (nike.apache.org: domain of remko.popma@gmail.com
 designates 209.85.212.170 as permitted sender)
Subject: Re: Extending Appenders
References: 
 <CALn20hJZ96fBDkT68PC5VYfYBL9_P-mSH3SPSTBmrb5MgfBDOg@mail.gmail.com>
 <CAAFrFhSra-j=hvDmToZnhZkVTeKUWENPYPJaddXaCwoVqHGxqg@mail.gmail.com>
 <CALn20hKn20kdHQuro5Q4vnhek9vf53BwAANc-fzBMOjKHKQ_7A@mail.gmail.com>
 <CAAFrFhRVLxyv2JK_ikAWpo4aq-v5q2f2+24=sa1BLPJbtSXsUw@mail.gmail.com>
 <41A8992A-E605-482A-8E58-282DDDFE4FFC@dslextreme.com>
 <8784959322575996390@unknownmsgid>
From: Remko Popma <remko.popma@gmail.com>
Content-Type: text/plain;
	charset=shift_jis
In-Reply-To: <8784959322575996390@unknownmsgid>
Message-Id: <47BED40E-4CCE-420E-91F8-789742B15EDC@gmail.com>
Date: Sat, 30 Aug 2014 09:19:18 +0200
To: Log4J Users List <log4j-user@logging.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)

This sounds like a good feature to have in log4j2. I remember we had an issu=
e at work where error logs were emailed automatically, bringing down the mai=
l server when the app kept generating the same error. Painful.=20

Sent from my iPhone

> On 2014/08/30, at 7:24, Michael Schall <mike.schall@gmail.com> wrote:
>=20
> Again, thanks for all the interest in my request.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> Mike
>=20
>> On Aug 29, 2014, at 11:28 PM, Ralph Goers <ralph.goers@dslextreme.com> wr=
ote:
>>=20
>> This is a fair point.  There are some things not in the API that we would=
n=81ft change as they would also break compatibility, such as the Layout or A=
ppender interface, but we aren=81ft guaranteeing that specific Appender or L=
ayout instances won=81ft have a new parameter added to them or things like t=
hat.
>>=20
>> Ralph
>>=20
>>> On Aug 29, 2014, at 3:22 PM, Remko Popma <remko.popma@gmail.com> wrote:
>>>=20
>>> I would not object to changing SmtpAppender to make it more extendible.
>>>=20
>>> Can you tell me more about your use case? SmtpAppender is designed this w=
ay
>>> because we had a specific usage in mind. By understanding your use case w=
e
>>> might be able to improve the design in a way that benefits not just you b=
ut
>>> other users as well. What do you want to do that you can't do with the
>>> current SmtpAppender?
>>>=20
>>> 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 u=
s
>>> some going back and forth.
>>>=20
>>> Thanks!
>>> Remko
>>>=20
>>>> On Friday, August 29, 2014, Michael Schall <mike.schall@gmail.com> wrot=
e:
>>>>=20
>>>> Thanks for your response Remko.
>>>>=20
>>>> Looking into this further, I could duplicate the SmtpAppender code as i=
t
>>>> 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 als=
o
>>>> like to override the sendEvents method, but then I run into issues beca=
use
>>>> the buffer is private.
>>>>=20
>>>> Do these changes seem like an issue?
>>>>=20
>>>> Mike
>>>>=20
>>>>=20
>>>> On Fri, Aug 29, 2014 at 4:51 PM, Remko Popma <remko.popma@gmail.com
>>>> <javascript:;>> wrote:
>>>>=20
>>>>> Looks like this class was made final in January 2013. The commit messa=
ge
>>>>> mentions checkstyle errors.
>>>>> What change are you proposing? Would just removing the final keyword f=
rom
>>>>> the class definition be enough to fulfill your needs?
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>>=20
>>>>> On Sat, Aug 30, 2014 at 4:07 AM, Michael Schall <mike.schall@gmail.com=

>>>> <javascript:;>>
>>>>> wrote:
>>>>>=20
>>>>>> 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?  D=
o
>>>>> we
>>>>>> really need to re-implement the the entire SMTPAppender (properties,
>>>>>> buffering, ...) to extend the appender?
>>>>>>=20
>>>>>> Thanks for your time.
>>>>>>=20
>>>>>> Mike
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>=20

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