ppkarwasz opened a new pull request, #385:
URL: https://github.com/apache/logging-log4j-samples/pull/385
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
