Reproduce `ThresholdFilter` GraalVM issue (#385)
* Reproduce `ThresholdFilter` GraalVM issue
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.
* fix: JUL and Logback tests
12 files changed
