Hi Mickael,

I agree it's good to make it clear about what we're going to adopt for the
logging library.
For keeping reload4j or adopting log4j2, I don't have any preference TBH.
But if Viktor is willing to drive log4j2 tasks, then we don't have any
reason not to adopt log4j2. (Thanks Viktor!)

Thanks
Luke


On Thu, Jan 11, 2024 at 4:02 AM Mickael Maison <mickael.mai...@gmail.com>
wrote:

> Hi,
>
> I think the only thing that would need to be done in 3.8 is the
> deprecation of the log4j appender (KIP-719). This was a pre-req for
> migrating to log4j2 due to conflicts when having both log4j and log4j2
> in the classpath. I don't know if that's still the case with reload4j
> but I think we should take the opportunity of deprecating it before
> 4.0 regardless to avoid relying on multiple logging libraries.
>
> Thanks,
> Mickael
>
> On Wed, Jan 10, 2024 at 7:58 PM Colin McCabe <cmcc...@apache.org> wrote:
> >
> > Hi Mickael,
> >
> > Thanks for bringing this up.
> >
> > If we move to log4j2 in 4.0, is there any work that needs to be done in
> 3.8? That's probably what we should focus on.
> >
> > P.S. My assumption is that if the log4j2 work misses the train, we'll
> stick with reload4j in 4.0. Hopefully this won't happen.
> >
> > best,
> > Colin
> >
> >
> > On Wed, Jan 10, 2024, at 09:13, Ismael Juma wrote:
> > > Hi Viktor,
> > >
> > > A logging library that requires Java 17 is a deal breaker since we
> need to
> > > log from modules that will only require Java 11 in Apache Kafka 4.0.
> > >
> > > Ismael
> > >
> > > On Wed, Jan 10, 2024 at 6:43 PM Viktor Somogyi-Vass
> > > <viktor.somo...@cloudera.com.invalid> wrote:
> > >
> > >> Hi Mickael,
> > >>
> > >> Reacting to your points:
> > >> 1. I think it's somewhat unfortunate that we provide an appender tied
> to a
> > >> chosen logger implementation. I think that this shouldn't be part of
> the
> > >> project in its current form. However, there is the sl4fj2 Fluent API
> which
> > >> may solve our problem and turn KafkaLog4jAppender into a generic
> > >> implementation that doesn't depend on a specific library given that
> we can
> > >> upgrade to slf4j2. That is worth considering.
> > >> 2. Since KIP-1013 we'd move to Java17 anyways by 4.0, so I don't feel
> it's
> > >> a problem if there's a specific dependency that has Java17 as the
> minimum
> > >> supported version. As I read though from your email thread with the
> log4j2
> > >> folks, it'll be supported for years to come and log4j3 isn't yet
> stable.
> > >> Since we already use log4j2 in our fork, I'm happy to contribute to
> this,
> > >> review PRs or drive it if needed.
> > >>
> > >> Thanks,
> > >> Viktor
> > >>
> > >> On Wed, Jan 10, 2024 at 3:58 PM Mickael Maison <
> mickael.mai...@gmail.com>
> > >> wrote:
> > >>
> > >> > I asked for details about the future of log4j2 on the logging user
> list:
> > >> > https://lists.apache.org/thread/6n6bkgwj8tglgdgzz8wxhkx1p1xpwodl
> > >> >
> > >> > Let's see what they say.
> > >> >
> > >> > Thanks,
> > >> > Mickael
> > >> >
> > >> > On Wed, Jan 10, 2024 at 3:23 PM Ismael Juma <m...@ismaeljuma.com>
> wrote:
> > >> > >
> > >> > > Hi Mickael,
> > >> > >
> > >> > > Thanks for starting the discussion and for summarizing the state
> of
> > >> > play. I
> > >> > > agree with you that it would be important to understand how long
> log4j2
> > >> > > will be supported for. An alternative would be sl4fj 2.x and
> logback.
> > >> > >
> > >> > > Ismael
> > >> > >
> > >> > > On Wed, Jan 10, 2024 at 2:17 PM Mickael Maison <
> > >> mickael.mai...@gmail.com
> > >> > >
> > >> > > wrote:
> > >> > >
> > >> > > > Hi,
> > >> > > >
> > >> > > > Starting a new thread to discuss the current logging situation
> in
> > >> > > > Kafka. I'll restate everything we know but see the [DISCUSS]
> Road to
> > >> > > > Kafka 4.0 if you are interested in what has already been said.
> [0]
> > >> > > >
> > >> > > > Currently Kafka uses SLF4J and reload4j as the logging backend.
> We
> > >> had
> > >> > > > to adopt reload4j in 3.2.0 as log4j was end of life and has a
> few
> > >> > > > security issues.
> > >> > > >
> > >> > > > In 2020 we adopted KIP-653 to upgrade to log4j2. Due to
> > >> > > > incompatibilities in the configuration mechanism with
> log4j/reload4j
> > >> > > > we decide to delay the upgrade to the next major release, Kafka
> 4.0.
> > >> > > >
> > >> > > > Kafka also currently provides a log4j appender. In 2022, we
> adopted
> > >> > > > KIP-719 to deprecate it since we wanted to switch to log4j2. At
> the
> > >> > > > time Apache Logging also had a Kafka appender that worked with
> > >> log4j2.
> > >> > > > They since deprecated that appender in log4j2 and it is not
> part of
> > >> > > > log4j3. [1]
> > >> > > >
> > >> > > > Log4j3 is also nearing release but it seems it will require
> Java 17.
> > >> > > > The website states Java 11 [2] but the artifacts from the latest
> > >> 3.0.0
> > >> > > > beta are built for Java 17. I was not able to find clear
> maintenance
> > >> > > > statement about log4j2 once log4j3 gets released.
> > >> > > >
> > >> > > > The question is where do we go from here?
> > >> > > > We can stick with our plans:
> > >> > > > 1. Deprecate the appender in the next 3.x release and plan to
> remove
> > >> > it in
> > >> > > > 4.0
> > >> > > > 2. Do the necessary work to switch to log4j2 in 4.0
> > >> > > > If so we need people to drive these work items. We have PRs for
> these
> > >> > > > with hopefully the bulk of the code but they need
> > >> > > > rebasing/completing/reviewing.
> > >> > > >
> > >> > > > Otherwise we can reconsider KIP-653 and/or KIP-719.
> > >> > > >
> > >> > > > Assuming log4j2 does not go end of life in the near future (We
> can
> > >> > > > reach out to Apache Logging to clarify that point.), I think it
> still
> > >> > > > makes sense to adopt it. I would also go ahead and deprecate our
> > >> > > > appender.
> > >> > > >
> > >> > > > Thanks,
> > >> > > > Mickael
> > >> > > >
> > >> > > > 0:
> https://lists.apache.org/thread/q0sz910o1y9mhq159oy16w31d6dzh79f
> > >> > > > 1: https://github.com/apache/logging-log4j2/issues/1951
> > >> > > > 2: https://logging.apache.org/log4j/3.x/#requirements
> > >> > > >
> > >> >
> > >>
>

Reply via email to