You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Colin McCabe <cm...@apache.org> on 2017/11/17 18:16:27 UTC
Adding log4j-extras to Apache Kafka?
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
Re: Adding log4j-extras to Apache Kafka?
Posted by Colin McCabe <cm...@apache.org>.
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 <is...@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 <cm...@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 <cm...@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
> > > > >
> > >
> >
Re: Adding log4j-extras to Apache Kafka?
Posted by Ismael Juma <is...@juma.me.uk>.
The slf4j conversion is nearly done, I expect it to be merged by tomorrow.
The main challenge in moving to log4j2 by default is that the configuration
is not compatible. If there's a way to support the old configuration, then
we can go straight to log4j2.
Ismael
On Wed, Nov 22, 2017 at 12:52 AM, Xavier Léauté <xa...@confluent.io> 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 <is...@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 <cm...@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 <cm...@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
> > > > >
> > >
> >
>
Re: Adding log4j-extras to Apache Kafka?
Posted by Xavier Léauté <xa...@confluent.io>.
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 <is...@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 <cm...@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 <cm...@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
> > > >
> >
>
Re: Adding log4j-extras to Apache Kafka?
Posted by Ismael Juma <is...@juma.me.uk>.
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 <cm...@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 <cm...@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
> > >
>
Re: Adding log4j-extras to Apache Kafka?
Posted by Colin McCabe <cm...@apache.org>.
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 <cm...@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
> >
Re: Adding log4j-extras to Apache Kafka?
Posted by Viktor Somogyi <vi...@gmail.com>.
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 <cm...@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
>