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.po...@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.sch...@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.po...@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.sch...@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: garydgreg...@gmail.com | ggreg...@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
