I was under the impression that the log4j2 configuration file syntax was different than that of the original log4j. The log4j 2 documentation seems to confirm this (see https://logging.apache.org/log4j/2.x/manual/migration.html ):
> Although the Log4j 2 configuration syntax is different than that of > Log4j 1.x, most, if not all, of the same functionality is available. So that would prevent us from moving to log4j2, except in a compatibility-breaking 2.0 release. best, Colin On Tue, Nov 21, 2017, at 16:52, Xavier Léauté wrote: > Is there anything that would prevents us from moving directly to log4j2 > as > the default log backend – independently of our efforts to move remaining > pieces to sl4fj? Unless we have some very custom code, it should be > possible to rely on log4j-1.2-api.jar to avoid having to migrate > everything > at once, but still benefit from appenders already included with log4j2 > (e.g. RollingFileAppender is already built into log4j2 core) > > On Tue, Nov 21, 2017 at 4:16 PM Ismael Juma <ism...@juma.me.uk> wrote: > > > Hi Colin, > > > > I think it's reasonable to include log4j-extras with the broker in the next > > release (1.1.0). In the 2.0.0 timeframe, we may decide to move to log4j2 > > (or logback), but people can benefit from log4j-extras in the meantime. > > > > Ismael > > > > On Tue, Nov 21, 2017 at 11:50 PM, Colin McCabe <cmcc...@apache.org> wrote: > > > > > Hi Viktor, > > > > > > I was under the impression that slf4j is just a facade over the > > > underlying log library. So the good thing about moving to slf4j is that > > > it will allow us to more easily migrate to a new log library (logback, > > > log4j2, etc.) in the future if we want. slf4j is also better for > > > library code, because it allows the library user to continue using their > > > own logging library, rather than adopting ours. > > > > > > But I don't see why moving to slf4j would make log4j-extras less useful > > > to us. Perhaps I'm missing something? > > > > > > Also, just to clarify, I was proposing including log4j-extras with the > > > Kafka brokers, not as a dependency of the producer, consumer, or other > > > library code. > > > > > > best, > > > Colin > > > > > > > > > On Tue, Nov 21, 2017, at 06:25, Viktor Somogyi wrote: > > > > Hi Colin, > > > > > > > > Currently we are moving away from directly referencing log4j to using > > > > slf4j > > > > instead (KAFKA-1044). As this jira only aims to remove some runtime > > > > dependencies we still need more work but eventually users will be able > > to > > > > change to their own implementation. > > > > > > > > Despite all this the current default is still log4j and I think it > > would > > > > be > > > > a valuable conversation to have that what whether we keep it as a > > default > > > > in the future (it's quite old but with log4j-extras it can be a > > > > competition) or we change to others, like Log4j2 or Logback? > > > > > > > > What do you think? > > > > > > > > Viktor > > > > > > > > > > > > On Fri, Nov 17, 2017 at 7:16 PM, Colin McCabe <cmcc...@apache.org> > > > wrote: > > > > > > > > > I'm curious if there is a reason we do not include log4j-extras in > > > > > Kafka. If we had it, users could configure RollingFileAppender with > > > > > compression. > > > > > > > > > > best, > > > > > Colin > > > > > > > > > >
