-
Notifications
You must be signed in to change notification settings - Fork 40.6k
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
Native compiled executable prints log4j2 exception/warning when both Netty and JBoss Logging are on the classpath #33113
Comments
It seems I can work around the issue by adding this exclusion in my
|
I have a similar issue in Gradle, but the error is shown only when triggering the run from ./gradlew nativeRun, and then stopping the app. My app uses SLF4J API for logging, and if I simply launch the application from build/nativeCompile/..., no error is shown. So maybe the issue is with the way the plugins register/trigger the run commands and/or the logger they use. The proposed workaround (excluding log4j-to-slf4j) seems to solve the issue. |
Thanks for reporting this, @wimdeblauwe. It's an unfortunate combination of the way that JBoss Logging behaves and Log4j2, even just its API jar, not playing nicely with GraalVM. We include |
We've seen somewhat similar behavior. In theory, any application that uses JBoss logging should be affected. However, that is not the case. It appears that something (initialization order?) causes JBoss Logging to behave differently so the problem doesn't always occur. |
When configured to try using SLF4J, JBoss Logging relies upon reflection to analyse the methods of
|
When |
In our Hibernate Validator smoke test, we don't see the unwanted error-level logging. This is because the attempt to use Log4j2 fails differently:
It's failed earlier and, crucially, before the point at which the Log4j2 API jar performs the unwanted logging. I don't yet understand why, apparently, it would sometimes be possible to call |
|
I've opened oracle/graalvm-reachability-metadata#108 to fix the reachability metadata for Netty. With this change in place, Log4j2 no longer performs the error-level logging of the exception. Until this change is available, please continue to exclude the I've also opened #33155 to address the different providers on the JVM and in a native image that was discovered while investigating this issue. |
I have a CLI tool using Spring Boot 3.0.0.RC2 with Spring Shell. When I compile it natively and run it, it suddenly now prints this at the start:
To be clear: this is not printed when running on the JVM.
I am not using Log4j2, it is not in my dependency tree:
I compiled on macOS using GraalVM:
Let me know if you need more info. The project can be viewed at https://github.com/wimdeblauwe/ttcli
The text was updated successfully, but these errors were encountered: