[MS21] Native Compilation Support #1

[ppkarwasz]

This is the first milestone devoted to fixing GraalVM support in Log4j.

Tasks

• Fix GraalVM support in log4j-api (Backport some Log4j API 3.x features #2392),
• Automatically check GraalVM compatibility for each Log4j API implementation (apache/logging-log4j-samples@94c819e)
• Release Log4j API 2.24.0
• Create and validate a plan to introduce GraalVM support in Log4j Core and the remaining modules. This is discussed in GraalVM wishlist #2364.

[vy]

@ppkarwasz, I'd really appreciate a dedicated manual/native.adoc such that:

• It is linked from a bridging section in installation.adoc (at the bottom?)
• It is nested under Installation in nav.adoc

I am leaving the decision of choosing a milestone to address this task to you.

[ppkarwasz]

@vy,

I added the documentation task to #2831.

[ppkarwasz]

A set of integration tests has been scheduled daily. See CI run 10638659451 for example.

Note the the simple test case will fail until #2908 is merged.

[ppkarwasz]

The CI run 10647359122 gives a green light for a 2.24.0 release.

The 2.24.0 RC1 artifacts were checked by this run.

[ppkarwasz]

The 2.24.0 release has just shipped with GraalVM support out-of-the box in the API

Regarding GraalVM support in the rest of Log4j, the plan is as follows:

1. Extend log4j-docgen to be able to generate GraalVM reflection metadata.
2. Publish the reachability metadata on oracle/graalvm-reachability-metadata with all the plugins.

[vy]

Extend log4j-docgen to be able to generate GraalVM reflection metadata.

Why do we use log4j-docgen but not log4j-plugins instead to generate this metadata?

[ppkarwasz]

I guess we can extend log4j-plugin-processor to generate code for each configuration attribute, this way no reflection metadata is necessary. WDYT?