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 mike.schall@gmail.com
 designates 209.85.217.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACmp6krdcUpqGq_O_-h1UW9KqV4PDLWr8Ew5uE00yFNw8-aNdw@mail.gmail.com>
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>
	<47BED40E-4CCE-420E-91F8-789742B15EDC@gmail.com>
	<ECFB496F-3D6C-47E4-8F74-4B7CFE2ABDE3@bitgladiator.com>
	<CACmp6krdcUpqGq_O_-h1UW9KqV4PDLWr8Ew5uE00yFNw8-aNdw@mail.gmail.com>
Date: Tue, 2 Sep 2014 11:08:45 -0500
Message-ID: 
 <CALn20hJaFFpVTuL42bfXSn6FrnJ1CB8pmkDeNC2BAZ5DLe-9JQ@mail.gmail.com>
Subject: Re: Extending Appenders
From: Michael Schall <mike.schall@gmail.com>
To: Log4J Users List <log4j-user@logging.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2b8167cd51e0502175539

--001a11c2b8167cd51e0502175539
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 ju=
st
> 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 nee=
d
> > 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 dow=
n
> > 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 f=
or
> > >> example, we don't want to send thousands of emails if the network go=
es
> > >> 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 ma=
y
> > >> 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 fi=
le
> > >> 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=E2=80=99t change as they would also break compatibility, such as=
 the
> Layout
> > or Appender interface, but we aren=E2=80=99t guaranteeing that specific=
 Appender
> or
> > Layout instances won=E2=80=99t have a new parameter added to them or th=
ings 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 jus=
t
> > 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 cod=
e
> > 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 wou=
ld
> > also
> > >>>>> like to override the sendEvents method, but then I run into issue=
s
> > 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 whic=
h
> > >>>>> 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>
>

--001a11c2b8167cd51e0502175539--