Any rough idea when log4j3 GA will be released?

[ghevge]

Any rough idea when log4j3 GA will be released? Will it take ~2 years as log4j2 took or will it be faster ?
Thanks

[tcmot]

I don't think so. Log4j2 3.0 has not undergone any disruptive changes. Just deleted some modules, some features, and core functions without changing. I think GA will be released soon.

[ppkarwasz]

Currently we plan to release 3.0.0 around March 2024.

The main and 2.x branch diverged 5 years ago, which means there is some simple but tedious work to perform.
You can help with the release by:

• testing the betas that we will release every 2-3 weeks from now on,
• helping with the sync job: choose a module in [MS7] Branch main overhaul #2 #2016 (many contain just a couple of classes, e.g. log4j-mongodb4) and check with git diff 2.x main -- log4j-mongodb if there are some fixes applied to 2.x, but not to main.

[sergey-morenets]

Hi @ppkarwasz

Do you have any updates about 3.0 release date? You said it would be in March but it's already mid-May and I see only beta 2 released in February.

[ppkarwasz]

Hi @sergey-morenets,

We got sidetracked with some major changes in Log4j 3 (cf. #2273 and #2290). Since Log4j Core 3 depends on Log4j API 2 now, we need to release 2.24.0 before we can release any more betas of version 3.

Log4j API 2 also has a lot going on (see the #2438 proposal for example).

In the next weeks we should have a PMC meeting and we will sort things out. Maybe we can release 3.0.0-beta3 by the end of the month, which then will require extensive testing before we can promote it to GA.

[ghevge]

@ppkarwasz do you know if the Graal VM native image support will make it in log4j3 ? #1539

[ppkarwasz]

@ghevge,

The only obstacle to using Log4j with GraalVM was, as far as I know a direct call to LambdaMetaFactory (which GraalVM does not support) in log4j-api. This call was introduced in 2.19.0 and was removed in #2392, which will be released in 2.24.0.

With either 2.18.0 or 2.24.0 you only need to generate reachability metadata and you can use Log4j Core with GraalVM. See #2364 for details.

[ghevge]

@ppkarwasz Thanks for the response. I've already tried with 2.22.0 version a couple of month ago and was not working. And everyone on the internet at that time was pointing to a log4j2 issue. Even today, a google search on the problem will eventually take you to the issue that was closed on Jira and I believed recreated in github. In #2364 you are mentioneing the issue #2392 which was only fixed in 2.24.0. Which is not released yet in the maven repo from what I see. I will wait for 2.24.0 and give it a second try. As a side note, maybe it will be a good idea to have a blogpost or an example somewhere, on how to set up log4j2 for native image compilation, as the procedure doesn't seem to be that straight forward.

[ppkarwasz]

@ghevge,

The procedure is the same as for Logback, except that some user posted reachability metadata for Logback to graalvm-reachability-metadata.

I'll add a GraalVM example to our samples, when I'll find the time.

[sergey-morenets]

I guess Log4j 3 should be released only if it's fully compatible with GraalVM.

[ppkarwasz]

I added an example of native Log4j application in our samples repository: log4j-samples-graalvm

The sample currently works and I'll check it before we release 2.24.0 and 3.0.0.

We'll look further into native image generation sometimes in Q4 2024. The goal would be to provide a tool that sizes down the native image based on the Log4j plugins that a user want to include. I am not sure we can reach it though.

[jengebr]

@ppkarwasz is there a target date for 2.24.0, and is there anything I can do to help with the release?

[ppkarwasz]

From my perspective the following features are missing in 2.24.0:

• Move ThreadContextMap implementations to log4j-core #2593, which also replaces DefaultThreadContextMap with the implementation you contributed,
• moving ScopedContext and ResourceLogger to a new artifact (see 2214 - Add support for ScopedContext #2385, Scoped context #2419 and Scoped context #2438). Since there is no consensus whether log4j-api should be enriched with these classes, personally I think that moving them to a new artifact is a way to reach consensus.

Feel free to contact me at the e-mail on my Github profile, so we can discuss how you could help in a video call.

[rgoers]

@ppkarwasz Please bring that up on the dev list. At the moment I would be -1 to moving them to some new artifact. However, depending on how the discussion evolves I might change my mind.

[ppkarwasz]

@rgoers,

Sure, I'll discuss the proposal on dev@logging as soon as I finish some preparatory work. I would prefer to have a hands-on discussion with some PRs and a document summarizing the pros and cons of ScopedContext, so that a larger group of users can understand the details of the proposal. Don't worry, I don't plan to merge anything until we come to an understanding.

The current status quo of 2.24.0 in my opinion bloats log4j-api, which is already huge. Since there are already artifacts like log4j-iostreams that constitute some sort of plugin-ins for Log4j API, I would be -1 on releasing 2.24.0 unmodified.