Upgrade to log4j 2.25.1

[Rassyan]

Upgrade to log4j 2.25.1
closes #132035

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[rjernst]

@elasticsearchmachine test this please

[rjernst]

@elasticmachine test this please

[mosche]

Looks like this is suffering from apache/logging-log4j2#3437

[mosche]

Updating this having merged #132238

[mosche]

@breskeby is looking into the transitive dependency issue mentioned above, this needs further fixes / improvements in our build to be properly handled.

[Rassyan]

Thanks for flagging this potential dependency concern.
Should any related adjustments become needed here, I'd be happy to help coordinate. Just let me know specific steps you'd like taken.

[breskeby]

@Rassyan Can you rebase against latest master? I think some thirdparty check tasks will start failing with the update that probably need to be adjusted too. You should be able to reproduce those by running ./gradlew precommit. Let me know if you want help from our side to tackle those issues

[Rassyan]

Hi @breskeby,

Thanks for the pointer. I've rebased onto the latest main (which includes your #134169) and now encounter a dependency resolution failure when running ./gradlew precommit, even before applying my Log4j upgrade changes.

The error occurs in the :benchmarks:compileJava configuration:

* What went wrong:
Could not determine the dependencies of task ':benchmarks:compileJava'.
> Could not resolve all dependencies for configuration ':benchmarks:compileClasspath'.
   > Unexpected state for resolution: Unknown

This suggests the new component metadata rules might be conflicting with the benchmarks project's dependency graph. Could this be the kind of third-party check failure you anticipated?

I'm not sure what adjustments are needed here, as the issue seems related to the new dependency resolution setup. Could you please take a look when you have a moment?

Thanks!

[breskeby]

can you run the build with --stacktrace? and share the output (maybe a bulid scan or share directly here). you likely need add the transitive provided dependencies now to the verification file in gradle/*.

you can do that automatically by running the precommit with ----write-verification-metadata sha256

[Rassyan]

Thanks @mosche! 🙌 Just pushed the change. Really appreciate your guidance through this - it's been a great learning experience collaborating with you. Excited to see the test results! 🚀

[mosche]

@elasticmachine test this please

[mosche]

@Rassyan could you run the test suites below, there's some more warnings.

./gradlew :qa:evil-tests:test
./gradlew :qa:logging-config:test

Specifically No Root logger was configured, creating default ERROR-level Root logger with Console appender sounds concerning. There seems to be a difference in behavior.

[Rassyan]

Hi @mosche,

I dug into EvilLoggerConfigurationTests#testLoggingLevelsFromSettings to compare behavior between Log4j 2.19.0 and 2.25.1.

In both versions, the warning “No Root logger was configured, creating default ERROR-level Root logger with Console appender” is present. The key difference is in how they handle the status listener:

• In 2.19.0, during initialization, StatusConfiguration#configureExistingStatusConsoleListener silently changes the registered WARN-level listener to ERROR-level (see attached debug screenshot).
• In 2.25.1, this doesn’t happen — the listener level remains unchanged (likely due to Make StatusLogger self-contained and testable apache/logging-log4j2#2249).

This level shift in 2.19.0 breaks ESTestCase#checkStaticState, which expects WARN-level events.

I’m unsure whether we should suppress these warnings or address the listener behavior directly. Would you have any advice on how you’d like to proceed? I’m happy to help implement the right fix.

Attached:

• Screenshot comparing WARN output in 2.19.0 vs 2.25.1
• Screenshot showing listener level being overridden in 2.19.0

[mosche]

That's a great find, thanks for digging into that!
I have a changeset pending here that ignores those additional warnings, just didn't get to investigate the one you looked into 🎉 I'll push asap.
And there's another stupid issue where log levels were set to deprecation, the old version of log4j2 was apparently more tolerant / didn't complain about it 🤷

[mosche]

@elasticmachine test this please

[mosche]

@elasticmachine test this please

[mosche]

@elasticmachine test this please

[mosche]

@elasticmachine test this please

[rjernst]

LGTM

[mosche]

@elasticmachine test this please

[mosche]

CI surfaced a log4j2 concurrency bug
apache/logging-log4j2#3940

[jeramysoucy]

@Rassyan I do not see any changes to code owned by our team (kibana-security). I am guessing this was auto-triggered but no longer relevant, but wanted to check in with youy before I removed our team. Is there anything we should look at here?

[mosche]

pending on this log4j2 fix apache/logging-log4j2#3955