Run helmut4 client in debug mode

Disclaimer

Important The connection speed & response will be significant slower, as everything will be logged

If you need to debug the local helmut4 client on windows or macintosh clients you can do this with the following commands.

Please keep in mind that this should only be used for debugging purpose not for daily use!

Windows

Open a command prompt (with admin privileges) and execute this command:

"C:\Program Files\MoovIT GmbH\Helmut4\jre\bin\java.exe" -jar "C:\Program Files\MoovIT GmbH\Helmut4\HelmutClient.jar" --logging.level.org=DEBUG

Macintosh

Open a terminal window and execute the following two commands (with admin privileges)

"/Applications/Helmut4.app/Contents/Resources/jre/bin/java" -jar "/Applications/Helmut4.app/Contents/Resources/HelmutClient.jar" --logging.level.org=DEBUG

Debug Options

How to Choose the Right Level:

  • TRACE: Use for highly detailed debugging during development.

  • DEBUG: Use for regular debugging when specific issues occur.

  • INFO: Use for monitoring normal application operations in production.

  • WARN: Use to track potential problems without flooding logs.

  • ERROR: Use for critical issues requiring immediate attention.

  • FATAL: Use to identify severe errors leading to system failure.

  • OFF: Use to disable logging entirely.

Debug level

Here’s a detailed explanation of the logging levels you can configure for your application:

1. OFF

  • Purpose: Turns off logging entirely.

  • Use case: When you want to disable all logging, typically in production for maximum performance.

  • Behavior: No logs will be recorded or output, regardless of the severity.

2. FATAL

  • Purpose: Logs critical errors that cause the application to terminate unexpectedly.

  • Use case: Detecting system crashes or unrecoverable states.

  • Behavior: Only logs events of FATAL severity.

  • Example: A missing critical resource or an exception causing immediate shutdown.

3. ERROR

  • Purpose: Logs errors that affect the normal operation but don’t cause the application to crash.

  • Use case: Debugging runtime issues or failures in specific operations.

  • Behavior: Logs ERROR and FATAL events.

  • Example: A failed database connection or invalid user input causing a function to fail.

4. WARN

  • Purpose: Logs potentially harmful situations that could indicate a problem.

  • Use case: Monitoring for conditions that don’t cause errors but may require attention.

  • Behavior: Logs WARN, ERROR, and FATAL events.

  • Example: Deprecated API usage or a configuration mismatch.

5. INFO

  • Purpose: Logs general information about the application’s progress or state.

  • Use case: Standard logging for normal operations.

  • Behavior: Logs INFO, WARN, ERROR, and FATAL events.

  • Example: Application startup messages, configuration details, or status updates.

6. DEBUG

  • Purpose: Logs detailed information primarily useful for developers during debugging.

  • Use case: Troubleshooting issues or understanding internal workflows.

  • Behavior: Logs DEBUG, INFO, WARN, ERROR, and FATAL events.

  • Example: Method entry and exit points, parameter values, or intermediate states.

7. TRACE

  • Purpose: Logs very detailed information, including fine-grained events within the application.

  • Use case: Deep debugging to trace execution paths or diagnose complex issues.

  • Behavior: Logs all events, including TRACE, DEBUG, INFO, WARN, ERROR, and FATAL.

  • Example: Low-level details such as thread states, detailed computations, or internal operations.

Last updated