logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Extending Appenders
Date Sat, 30 Aug 2014 03:42:26 GMT
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 <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 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 <mike.schall@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
> > > >
> > >
> >
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message