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