Reproduce ThresholdFilter GraalVM issue
#385
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change reproduces the issue described in apache/logging-log4j2#3871, where configurations that include `ThresholdFilter` (or any other Log4j filter) fail to work correctly when building a GraalVM native image. The root cause is a mismatch in how parameter types are represented in `reflect-config.json`: * The existing metadata stores parameter types using their canonical class name (JLS §6.7). * However, GraalVM expects the binary class name (JLS §13.1). This is especially relevant for nested types: * Canonical name: `org.apache.logging.log4j.core.Filter.Result` * Binary name: `org.apache.logging.log4j.core.Filter$Result` * For array types, GraalVM accepts either: * the JVM descriptor form (`[L<component_type>;`), or * the Java-like form (`<component_type>[]`). This PR introduces tests that intentionally fail for the `log4j-core` and `log4j-core-jtl` profiles, because they rely on the embedded reachability metadata in Log4j Core, which currently uses canonical names. In contrast, the `log4j-core-minimal` and `log4j-core-jtl-minimal` profiles rely on manually generated metadata, which has been updated in this PR to use the expected binary names and now works correctly under GraalVM.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change reproduces the issue described in apache/logging-log4j2#3871, where configurations that include
ThresholdFilter(or any other Log4j filter) fail to work correctly when building a GraalVM native image.The root cause is a mismatch in how parameter types are represented in
reflect-config.json:The existing metadata stores parameter types using their canonical class name (JLS §6.7).
However, GraalVM expects the binary class name (JLS §13.1). This is especially relevant for nested types:
org.apache.logging.log4j.core.Filter.Resultorg.apache.logging.log4j.core.Filter$ResultFor array types, GraalVM accepts either:
[L<component_type>;), or<component_type>[]).This PR introduces tests that intentionally fail for the
log4j-coreandlog4j-core-jtlprofiles, because they rely on the embedded reachability metadata in Log4j Core, which currently uses canonical names. In contrast, thelog4j-core-minimalandlog4j-core-jtl-minimalprofiles rely on manually generated metadata, which has been updated in this PR to use the expected binary names and now works correctly under GraalVM.