Skip to content

fix: Add GraalVM reachability metadata for non-plugin class instantiations #3800

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jul 4, 2025

Conversation

ppkarwasz
Copy link
Contributor

The GraalVmProcessor currently only generates metadata for Log4j plugins, overlooking other reflection usages in Log4j Core. This change adds reachability metadata for additional reflection cases to improve compatibility with GraalVM native images.

Fixed Cases

This PR addresses the following reflective instantiations:

  • Context selectors and reliability strategies: Ensures proper instantiation under GraalVM.
  • Configuration instantiation in DefaultConfigurationBuilder: Fixes support for the log4j2.properties configuration format when running on GraalVM.
  • BlockingQueue instantiation in JSON Template Layout: Enables GraalVM compatibility. Note: MpmcArrayQueue is not supported on GraalVM and must be fixed in the JCTools project.

Known Limitations (Explicitly Ignored)

The following cases are not addressed in this PR:

  • JMX classes in log4j-1.2-api: While GraalVM supports JMX, usage of Log4j 1.x’s JMX interface is likely minimal.
  • MulticastDnsAdvertiser: This feature is probably unused and could pose a security risk by advertising log file locations via mDNS.

…tions**

The `GraalVmProcessor` currently only generates metadata for Log4j plugins, overlooking other reflection usages in Log4j Core. This change adds reachability metadata for additional reflection cases to improve compatibility with GraalVM native images.

### Fixed Cases

This PR addresses the following reflective instantiations:

* **Context selectors and reliability strategies:** Ensures proper instantiation under GraalVM.
* **`Configuration` instantiation in `DefaultConfigurationBuilder`:** Fixes support for the `log4j2.properties` configuration format when running on GraalVM.
* **`BlockingQueue` instantiation in JSON Template Layout:** Enables GraalVM compatibility. Note: `MpmcArrayQueue` is not supported on GraalVM and must be fixed in the JCTools project.

### Known Limitations (Explicitly Ignored)

The following cases are *not* addressed in this PR:

* **JMX classes in `log4j-1.2-api`:** While GraalVM supports JMX, usage of Log4j 1.x’s JMX interface is likely minimal.
* **`MulticastDnsAdvertiser`:** This feature is probably unused and could pose a security risk by advertising log file locations via mDNS.
@ppkarwasz ppkarwasz added this to the 2.25.1 milestone Jul 3, 2025
@ppkarwasz ppkarwasz requested a review from vy July 3, 2025 19:22
@ppkarwasz ppkarwasz added the graalvm Issue related to GraalVM support label Jul 4, 2025
@ppkarwasz
Copy link
Contributor Author

Since we can't add inline comments to JSON files, it's worth providing a detailed explanation of this PR here.

There are two main types of non-plugin reflection usage in the codebase:

  1. Class availability checks (e.g., Loader.isClassAvailable)
    These calls are typically used to check whether a class is present on the classpath. In theory, we should include an entry in reflect-config.json with just the name property to ensure the class is considered reachable by GraalVM and not trimmed.
    However, in the cases I reviewed, such entries would be redundant. For example, YamlConfigurationFactory uses reflection to check for the presence of com.fasterxml.jackson.dataformat.yaml.YAMLFactory, but it also references YamlConfiguration, which directly depends on that same class. So GraalVM will already consider it reachable. All isClassAvailable usages I found fell into this category.

  2. Reflective instantiation (e.g., Loader.newInstance)
    These calls require explicit entries in reflect-config.json that declare the <init> constructor. Even if GraalVM doesn't trim the class itself, it won't allow reflective instantiation unless the constructor is properly declared in the config. This PR adds such entries where necessary to ensure compatibility.

@ppkarwasz ppkarwasz requested a review from Copilot July 4, 2025 12:46
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR enhances GraalVM native image support by adding reflection reachability metadata for non-plugin class instantiations in Log4j.

  • Introduces a changelog entry documenting the GraalVM fixes.
  • Adds reflect-config.json for JSON Template Layout (blocking queue constructors).
  • Adds reflect-config.json for Log4j Core (configuration builders, context selectors, reliability strategies).

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
src/changelog/.2.x.x/3800_graalvm-misc-reflection.xml New entry to document GraalVM compatibility fixes
log4j-layout-template-json/.../reflect-config.json Registers MpmcArrayQueue and ArrayBlockingQueue constructors
log4j-core/.../reflect-config.json Registers constructors for core config builders, selectors, strategies
Comments suppressed due to low confidence (4)

src/changelog/.2.x.x/3800_graalvm-misc-reflection.xml:10

  • [nitpick] The changelog description is quite general; consider listing the specific reflection cases fixed (context selectors, reliability strategies, DefaultConfigurationBuilder, BlockingQueue) to give users clearer guidance.
    Resolves `PropertiesConfiguration` compatibility issues with GraalVM and addresses additional minor reflection-related problems.

log4j-core/src/main/resources/META-INF/native-image/org.apache.logging.log4j/log4j-core/reflect-config.json:1

  • There are no tests verifying that these GraalVM reflect-config metadata entries are actually picked up; consider adding integration or CI tests to validate native image reachability for the newly added classes.
[

log4j-core/src/main/resources/META-INF/native-image/org.apache.logging.log4j/log4j-core/reflect-config.json:1

  • [nitpick] Indentation in this JSON file differs from the project's standard (2 spaces here vs. 4 elsewhere); normalizing formatting will improve consistency.
[

src/changelog/.2.x.x/3800_graalvm-misc-reflection.xml:1

  • [nitpick] The changelog directory is named .2.x.x with a leading dot, which may be unintentional; aligning it with other version directories (e.g., 2.x.x without a dot) will follow project conventions.
<?xml version="1.0" encoding="UTF-8"?>

Copy link
Member

@vy vy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Thanks for the elaborate explanation, much appreciated.

@ppkarwasz ppkarwasz merged commit cab8ae8 into 2.x Jul 4, 2025
11 checks passed
@ppkarwasz ppkarwasz deleted the fix/2.x/graalvm-misc-reflection branch July 4, 2025 16:43
@github-project-automation github-project-automation bot moved this from To triage to Done in Log4j bug tracker Jul 4, 2025
@ppkarwasz
Copy link
Contributor Author

The explanation might come handy in a couple of years after we have all forgotten why this was added. 😉

ppkarwasz added a commit that referenced this pull request Jul 5, 2025
…tions (#3800)

The `GraalVmProcessor` currently only generates metadata for Log4j plugins, overlooking other reflection usages in Log4j Core. This change adds reachability metadata for additional reflection cases to improve compatibility with GraalVM native images.

### Fixed Cases

This PR addresses the following reflective instantiations:

* **Context selectors and reliability strategies:** Ensures proper instantiation under GraalVM.
* **`Configuration` instantiation in `DefaultConfigurationBuilder`:** Fixes support for the `log4j2.properties` configuration format when running on GraalVM.
* **`BlockingQueue` instantiation in JSON Template Layout:** Enables GraalVM compatibility. Note: `MpmcArrayQueue` is not supported on GraalVM and must be fixed in the JCTools project.

### Known Limitations (Explicitly Ignored)

The following cases are *not* addressed in this PR:

* **JMX classes in `log4j-1.2-api`:** While GraalVM supports JMX, usage of Log4j 1.x’s JMX interface is likely minimal.
* **`MulticastDnsAdvertiser`:** This feature is probably unused and could pose a security risk by advertising log file locations via mDNS.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
graalvm Issue related to GraalVM support
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants