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 yo
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 S
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 bur
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 issu
: 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 Sch
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
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
d
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
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,
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
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 (FactoryD
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 nee
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-imple
gging.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
reamAppender 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.619
15 matches
Mail list logo