[MS24] Native Compilation Support #4

[ppkarwasz]

This is the final milestone, after #2832, devoted to fixing GraalVM support in Log4j.

Tasks

• Fix GraalVM support in all remaining Log4j modules.

Additional tasks

Since the main was achieved in the previous #2831 milestone, we profit from the occasion to complete the following tasks:

• Add a tool to manipulate plugin descriptors logging-log4j-transform#139
• Add customized GraalVM profiles logging-log4j-samples#213

[ppkarwasz]

The tool developed in apache/logging-log4j-transform#139 allows advanced users to hand pick which of the over 300 Log4j Plugins will be available in their GraalVM image.

Since Log4j Plugins are accessed by Log4j exclusively by reflection, removing the plugins for the GraalVM reachability metadata will effectively remove their code from the native image. This allows users to:

• Have smaller applications. The size of a sample GraalVM "Hello World!" application are available in the log4j-samples-graalvm project description.

Note

While we observe size differences of the order of 10 MiB in a "Hello World!" application, most of the additional code is due to additional JRE classes used by more advanced logging backends.
In a typical application the differences will be a couple of orders of magnitude smaller.

• Have a smaller exposure to vulnerabilities. Vulnerabilities in Log4j Plugins, which are not compiled in the application, will not affect the user. As an example, the famous CVE-2021-44228 would not affect user, unless they have both the PatternLayout and jndi lookup plugins.

[grobmeier]

Thanks!