Illegal reflective access warnings when running Netty with Java 9 #7817
Milestone
Comments
|
-Dio.netty.tryReflectionSetAccessible=false |
|
When I set that to false |
|
It's not an error, it's a debug message with a stacktrace, change your logger level to something else apart from debug eg. info or warn. |
|
exactly like @johnou said. Closing |
|
Where did you add this property? |
|
@marcelolfilho pass it into the JVM with the -D switch or use System.setProperty before initialising Netty. |
|
I know it's just a warning, but I tried to use the JVM parameter with version |
Closed
As I explained on neo4j/neo4j-java-driver#857, this is just a warning, but it produces a big ugly stack trace, which will likely confuse the end-users and cause many unnecessary support requests. Please, could this issue be reopened, or another one created to perform this probing differently? The generated exception could be thrown and a smaller warning only could be reported. AFAIK, in JDK11 |
chrisvest
added a commit
to chrisvest/netty
that referenced
this issue
Apr 16, 2021
Motivation: We are increasingly running in environments where Unsafe, setAccessible, etc. are not available. When debug logging is enabled, we log a complete stack trace every time one of these initialisations fail. Seeing these stack traces can cause people unnecessary concern. For instance, people might have alerts that are triggered by a stack trace showing up in logs, regardless of its log level. Modification: We continue to print debug log messages on the result of our initialisations, but now we only include the full stack trace is _trace_ logging (or FINEST, or equivalent in whatever logging framework is configured) is enabled. Result: We now only log these initialisation stack traces when the lowest possible log level is enabled. Fixes netty#7817
normanmaurer
pushed a commit
that referenced
this issue
Apr 19, 2021
Motivation: We are increasingly running in environments where Unsafe, setAccessible, etc. are not available. When debug logging is enabled, we log a complete stack trace every time one of these initialisations fail. Seeing these stack traces can cause people unnecessary concern. For instance, people might have alerts that are triggered by a stack trace showing up in logs, regardless of its log level. Modification: We continue to print debug log messages on the result of our initialisations, but now we only include the full stack trace is _trace_ logging (or FINEST, or equivalent in whatever logging framework is configured) is enabled. Result: We now only log these initialisation stack traces when the lowest possible log level is enabled. Fixes #7817
normanmaurer
pushed a commit
that referenced
this issue
Apr 19, 2021
Motivation: We are increasingly running in environments where Unsafe, setAccessible, etc. are not available. When debug logging is enabled, we log a complete stack trace every time one of these initialisations fail. Seeing these stack traces can cause people unnecessary concern. For instance, people might have alerts that are triggered by a stack trace showing up in logs, regardless of its log level. Modification: We continue to print debug log messages on the result of our initialisations, but now we only include the full stack trace is _trace_ logging (or FINEST, or equivalent in whatever logging framework is configured) is enabled. Result: We now only log these initialisation stack traces when the lowest possible log level is enabled. Fixes #7817
raidyue
pushed a commit
to raidyue/netty
that referenced
this issue
Jul 8, 2022
Motivation: We are increasingly running in environments where Unsafe, setAccessible, etc. are not available. When debug logging is enabled, we log a complete stack trace every time one of these initialisations fail. Seeing these stack traces can cause people unnecessary concern. For instance, people might have alerts that are triggered by a stack trace showing up in logs, regardless of its log level. Modification: We continue to print debug log messages on the result of our initialisations, but now we only include the full stack trace is _trace_ logging (or FINEST, or equivalent in whatever logging framework is configured) is enabled. Result: We now only log these initialisation stack traces when the lowest possible log level is enabled. Fixes netty#7817
thescouser89
added a commit
to thescouser89/bacon
that referenced
this issue
Aug 10, 2022
When running on Java 11, Netty prints a scary *debug* message about not being able to access the Unsafe APIs. This is normal and just printed as a debug, but it looks like an error message. This commit adjusts our logging to only print Netty error messages instead. Sources: - https://stackoverflow.com/questions/64043706/java-lang-illegalaccessexception-class-io-netty-util-internal-platformdependent - netty/netty#7817 (comment) ``` It's not an error, it's a debug message with a stacktrace, change your logger level to something else apart from debug eg. info or warn. ```
2 tasks
thescouser89
added a commit
to project-ncl/bacon
that referenced
this issue
Aug 10, 2022
When running on Java 11, Netty prints a scary *debug* message about not being able to access the Unsafe APIs. This is normal and just printed as a debug, but it looks like an error message. This commit adjusts our logging to only print Netty error messages instead. Sources: - https://stackoverflow.com/questions/64043706/java-lang-illegalaccessexception-class-io-netty-util-internal-platformdependent - netty/netty#7817 (comment) ``` It's not an error, it's a debug message with a stacktrace, change your logger level to something else apart from debug eg. info or warn. ```
But the log has the words "Exception" !!!! Once this is fixed from stacktrace to debug, I request you to please update that comment stating the version in which the stacktrace has been converted to debug so that the world can start using that build onwards. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected behavior
Run without warnings.
Actual behavior
I get following warning,
I specified this system property,
-Dio.netty.tryReflectionSetAccessible=trueFound that this has been fixed in 4.1.21.Final version according to this link. But when I upgraded netty version to 4.1.22.Final, I still get the same warnings. To get rid of these warnings what should I do?
Netty version
4.1.22.Final
JVM version (e.g.
java -version)java version "9.0.4"
OS version (e.g.
uname -a)Ubuntu
The text was updated successfully, but these errors were encountered: