On Aug 10, 2013, at 6:31 PM, Henning Schmiedehausen wrote: > Hi, > > I was toying with the log4j 2 API for a new project and I stumbled over the > fact that it uses a generic for Appender<T> without actually being generic. > The only generic part is the Layout. So as a result there is this weird > construct of Appender<SomeSerializableType> which is actually dictated by the > layout in use.
I'm relatively new to the team, so I don't know much about the reasoning behind making Appender generic, so I can't speak to that. I'm not personally opposed to removing these generics, but that is a HUGE change. > This leads to really interesting constructs such as > > public abstract class AbstractDatabaseAppender<T extends > AbstractDatabaseManager> extends AbstractAppender<LogEvent> Well this is a very different case. The <LogEvent> here is about Layout, just as you said. The <T extends AbstractDatabaseManager> is completely unrelated to Layout and I am _not_ in favor of removing these generics. > I was wondering whether this is necessary as it makes the API very cumbersome > to use and read so I removed the generic from Appender and subsequently went > through the log4j 2 code base and mostly removed stuff that was no longer > needed once that was gone. The result is at > > https://github.com/apache/logging-log4j2/pull/1 The Apache GitHub repository is just a mirror of our SVN repository. We can't accept or use any pull requests there. You need to generate an SVN patch and attach it to whatever JIRA you create. (As such, you should close this pull request.) > I will also file a JIRA for this. > > I know that the 2.0 release should be coming soon (being at beta8), but I > feel that making that change in the API before it is set in stone with 2.0 > woulc be really beneficial for anyone who wants to port code to 2.0 / write > new code. I'm sure there will be plenty of discussion about this over the next few days. > Thanks for considering, > Henning Nick
