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