PaperMC
Option to Suppress or Simplify Exception Stack Traces in Logs
Requested Feature
I would like Velocity to support a configuration option that allows the server to only output the main error message, without printing the full Java exception stack trace.
For example, logs would show:
[ERROR]: [connected player] (/<player-ip>:<port>): unable to connect to server Lobby
instead of:
[ERROR]: [connected player] (/<player-ip>:<port>): unable to connect to server Lobby
io.netty.channel.AbstractChannel$AnnotatedConnectException: finishConnect(..) failed: Connection refused: /0.0.0.0:23301
Caused by: java.net.ConnectException: finishConnect(..) failed: Connection refused
at io.netty.channel.unix.Errors.newConnectException0(Errors.java:166) ~[velocity.jar:3.4.0-SNAPSHOT]
...
Why is this needed?
- Exception stack traces make production logs extremely verbose, which affects readability and log storage.
- For most scenarios, only the main error message is needed for troubleshooting.
- Current configuration options (log4j2.xml, JVM flags, system properties) do not allow suppressing these stack traces, as they are logged directly at the ERROR level with the throwable.
Alternative Solutions
I have tried using the log4j2.xml configuration file to change the logging pattern and suppress stack traces, but this does not work because the stack traces are always printed by the logger when a Throwable is provided, regardless of the pattern.
I have also tried adjusting system properties such as velocity.log-pattern and velocity.log-level, but these do not affect the stack trace output for errors.
Currently, the only workaround is to filter the logs externally (e.g., using grep or a log management tool), but this is inconvenient and does not solve the problem at the source.
As far as I know, there are no plugins or built-in options in Velocity to control or suppress stack trace output.
Additional Information
No response
Requested Feature
I would like Velocity to support a configuration option that allows the server to only output the main error message, without printing the full Java exception stack trace. For example, logs would show:
[ERROR]: [connected player] (/<player-ip>:<port>): unable to connect to server Lobbyinstead of:
[ERROR]: [connected player] (/<player-ip>:<port>): unable to connect to server Lobby io.netty.channel.AbstractChannel$AnnotatedConnectException: finishConnect(..) failed: Connection refused: /0.0.0.0:23301 Caused by: java.net.ConnectException: finishConnect(..) failed: Connection refused at io.netty.channel.unix.Errors.newConnectException0(Errors.java:166) ~[velocity.jar:3.4.0-SNAPSHOT] ...Why is this needed?
- Exception stack traces make production logs extremely verbose, which affects readability and log storage.
- For most scenarios, only the main error message is needed for troubleshooting.
- Current configuration options (log4j2.xml, JVM flags, system properties) do not allow suppressing these stack traces, as they are logged directly at the ERROR level with the throwable.
Alternative Solutions
I have tried using the log4j2.xml configuration file to change the logging pattern and suppress stack traces, but this does not work because the stack traces are always printed by the logger when a Throwable is provided, regardless of the pattern. I have also tried adjusting system properties such as velocity.log-pattern and velocity.log-level, but these do not affect the stack trace output for errors. Currently, the only workaround is to filter the logs externally (e.g., using grep or a log management tool), but this is inconvenient and does not solve the problem at the source. As far as I know, there are no plugins or built-in options in Velocity to control or suppress stack trace output.
Additional Information
No response
Would you say that this is the only value that designates suppression, or are there other connection-related logs that should also have or contain suppression?
For most scenarios, only the main error message is needed for troubleshooting.
Your example error:
[ERROR]: [connected player] (/
: ): unable to connect to server Lobby
does not indicate any source, though, and is an error that only happens when Velocity is misconfigured. Other errors, e.g. packet errors, are already suppressed by default.
Cleaning this up has generally been on the low priority todo list for a while, especially for network level stuff where the trace provides no real context
