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 > >
