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.

[lockhartja]

@ppkarwasz just wanted to pulse check the status of 2.24 or 3.0 -- thanks

[ppkarwasz]

@lockhartja,

Milestone 2.24.0 is almost complete and all issues have a PR. I'll cut a release, when those PRs are reviewed, which probably means the last week of August. The next beta of 3.x will be released shortly after.

You can help by testing those modifications and reviewing the PRs.

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

[dhakehurst]

Currently we plan to release 3.0.0 around March 2024.

any update on a v 3.0.0 release date ?

[ppkarwasz]

Since Log4j API 2.24.0 has been released, I will cut a 3.0.0-beta3 release soon.

There is a certain number of open PRs against the main branch, that improve the modularization (remove all the optional dependencies) of Log4j artifacts: #2916, #2921, #2924, #2935. You can help accelerating the release of beta3 by testing those PRs or expressing your opinion on the features that are being moved (e.g. do we even need JAnsi in 2024, when all the terminals support ANSI escapes natively).

[daniel-b2c2]

There is a certain number of open PRs against the main branch

Many thanks for keeping the process transparent 🙏

I see all but one is merged, and the open one looks like it's nearly concluded. Is it the case that you see there being 3 betas prior to the release, and do you still see the GA release happening before the end of the year?

Any indications around timeline would be awesome; Personally I'm desperate to see a version of log4j that doesn't require the merging of Log4J2Plugins.dat files as we're unable to do that easily within our obscure build system.

Thanks 👍

[ppkarwasz]

@daniel-b2c2,

The discussion about #2924 stagnated a little bit on this dev@logging thread. Since the objections brought forward did not concern the removal of the artifacts, I merged the PR and I will be able to make a beta3 release sometimes this week or the next one.

I am just waiting to review #3150 and #3154 and we'll be ready to go.

[ppkarwasz]

You can vote on 3.0.0-beta3 now: see the vote dev@logging thread.

[ppkarwasz]

I just released Apache Log4j Core 3.0.0-beta3.

This beta version fulfills my requirements for a GA release and starts the consensus building phase in the Apache Logging Services team. To speed up the GA release process, please:

• Test it. See the new migration to Log4j Core 3.x notes for details.
• Report issues in Github Issues.
• Provide feedback in our user support channels.

[daniel-b2c2]

@ppkarwasz I don't see log4j-iostreams and log4j-api in maven with a -beta3 tag, I only see a -beta2 tag. Is this expected?

[ppkarwasz]

Yes, it is to be expected.

Due to the API/Implementation separation the Log4j 2.x distribution is actually composed of:

1. The Log4j API.
2. Extensions to the Log4j API: log4j-iostreams and the X-to-Log4j API bridges, where X is a foreign logging API.
3. The reference Log4j API implementation (Log4j Core).
4. Extensions to Log4j Core: additional lookups, layouts, appenders and so on.
5. Two alternative Log4j API implementations: the Log4j API-to-JUL and Log4j API-to-SLF4J bridges.

Since there are no breaking changes in the Log4j API, the Log4j 3.x distribution only contains Log4j Core 3.x and its extensions (3. and 4.). It also contains a log4j-bom that references the appropriate versions of the artifacts in the groups 1. and 2. to use.

Note: for applications the usage of log4j-bom is highly recommended. It is the best way we know to ensure that transitive dependency versions are "aligned". For example, if your application has:

• a direct dependency on library B, which has a transitive dependency on log4j-api version X.
• a direct runtime dependency on log4j-core, which has a transitive dependency on log4j-api version Y.

you must ensure that version Y of log4j-api will be chosen by Maven. The BOM is the easiest way to do it.

[daniel-b2c2]

Just for thread completeness, using the BOM worked like a charm. Will remember to use this in future.

To speed up the GA release process, please:

• Test it.
• Report issues in Github Issues.
• Provide feedback in our user support channels.

Tested with new segregated async library and associated settings, works, no issues.

Any rough estimate for GA release?

🙏