Bugwards incompatibility in Log4j2 properties config parsing since 2.25.0

[rschmitt]

Description

A bad Log4j2 properties file will cause an exception to be thrown from PropertiesConfigurationBuilder, whereas previous versions would fall back to the default logging configuration. This is most likely to be encountered when a Log4j 1.2 properties file is named log4j2.properties or explicitly passed in using -Dlog4j.configurationFile instead of -Dlog4j.configuration, but it can also happen if the properties file is just plain malformed in a way that was tolerated in the past.

Configuration

Version: 2.25.0 and 2.25.1

Operating system: macOS Sequoia 15.5

JDK: Corretto 17.0.16 inter alia

Logs

[0] ~/src/logging-log4j2 # ./run.sh
Darwin 842f57b044d8 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22 19:53:27 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6041 arm64

Testing 2.24.3 with bad Log4j 1.2 properties config:
Testing 2.24.3 with bad Log4j 2.x properties config: 14:21:45.189 [main] ERROR org.example.App - error level message
Testing 2.24.3 with wrong properties config version: 14:21:45.742 [main] ERROR org.example.App - error level message

Testing 2.25.1 with bad Log4j 1.2 properties config:
Testing 2.25.1 with bad Log4j 2.x properties config: class org.apache.logging.log4j.core.config.ConfigurationException: No type attribute provided for component *
Testing 2.25.1 with wrong properties config version: class org.apache.logging.log4j.core.config.ConfigurationException: No type attribute provided for component log4j

Reproduction

Run ./run.sh:
https://github.com/rschmitt/logging-log4j2/tree/bad-config-eiie-repro

[ppkarwasz]

Hi @rschmitt,

Thank you for reporting this.

The behavior you're seeing stems from the fact that the Java Properties configuration format operates differently from the standard configuration formats (XML, JSON, YAML). It has evolved more in response to user requests than from adherence to the design principles followed by the other formats.

The fact that PropertiesConfigurationBuilder throws an exception instead of returning null on configuration errors is a known issue — see #3088. Version 2.25.0 didn’t fundamentally change that behavior, but it did extend it somewhat as a side effect of #3703. Now, configurations containing invalid or unrecognized content (outside of recognized prefixes like appender, logger, etc.) also result in exceptions.

While fixing #3088 remains on the table, recent discussion on the dev@logging list suggests that the direction we're leaning toward is actually the opposite — namely, moving toward a stricter, fail-fast model. That means configuration errors would consistently cause the entire configuration to fail, rather than silently falling back or continuing with missing components (while only logging WARN messages).

So while this behavior may seem abrupt or inconsistent today, it aligns more closely with where the project is headed in terms of robustness and transparency in configuration handling.

If you have thoughts or feedback on the proposal above, you're welcome to share them either by replying to the dev@logging mailing list thread or by posting your remarks here.

[rschmitt]

moving toward a stricter, fail-fast model

My recommendation is to do this intentionally and all at once. My fear is that every new version of Log4j2 is going to introduce validation for another specific case, and releasing it internally will require me yet again to find and fix a bunch of garbage logging configuration. I'd also prefer for strict validation to be not necessarily configurable, but enabled through a single code path, which I can patch to buy time.

[vy]

AFAICT, @rschmitt agrees with the new strict validation approach, yet he is concerned about the implications of rolling this behavioral change out piecemeal, instead of all-at-once. I will close this ticket, since this doesn't really qualify as an issue anymore.

My recommendation is to do this intentionally and all at once.

@rschmitt, would you be interested in taking this task on?

[rschmitt]

@vy If you want, you can ping me and I can run a build with the proposed validation changes to see what breaks. I don't have enough time or expertise in Log4j2 internals or the various Log4j2 configuration formats to take this on.

[ppkarwasz]

@rschmitt,

Since most of the issues you're encountering seem to stem from invalid log4j2.properties or log4j.properties files, you might find the Log4j Transform CLI Tool helpful. It can convert properties-based configurations into XML, which uses a more lenient configuration factory.

The tool is nearly ready for release, but I haven’t had a chance to finalize it since January — so for now, only snapshot builds are available via repository.apache.org.

You can find the full list of supported formats here.