Contribute to help us improve!

Are there edge cases or problems that we didn't consider? Is there a technical pitfall that we should add? Did we miss a comma in a sentence?

If you have any input for us, we would love to hear from you and appreciate every contribution. Our goal is to learn from projects for projects such that nobody has to reinvent the wheel.

Let's collect our experiences together to make room to explore the novel!

To contribute click on Contribute to this page on the toolbar.

Logging

To monitor and understand what the running application is doing it is essential to write logs. This article gives advice on how to do proper logging in an application.

General conventions

SLF4J

Use SLF4J, because it has become a de facto standard in Java
- Use the 'typical usage pattern' and not the fluent API.
- Consider Logback as implementation in Spring
- Consider JBoss Log Manager and the JBoss Logging facade as implementation in Quarkus

Naming conventions

The private static final member storing the logger instance should be called log.

Use a separate configuration per environment

When the configuration of the logger is environment specific the configuration should be stored in a separate file.

Use standard log levels

To make it possible to filter the log messages, there are different log levels to express the nature of the logged message. There is a common understanding how this log levels should be used and which messages should be logged with which log level:

Log levels
Log-level	logger function	Description	Impact
FATAL	error with a marker	Only used for fatal errors that prevent the application to work at all (e.g. startup fails or shutdown/restart required)	Operator has to react immediately
ERROR	error	An abnormal error indicating that the processing failed due to technical problems.	Operator should check for known issue and otherwise inform development
WARNING	warn	A situation where something worked not as expected. E.g. a business exception or user validation failure occurred.	No direct reaction required. Used for problem analysis.
INFO	info	Important information such as context, duration, success/failure of request or process	No direct reaction required. Used for analysis.
DEBUG	debug	Development information that provides additional context for debugging problems.	No direct reaction required. Used for analysis.
TRACE	trace	Like DEBUG but exhaustive information and for code that is run very frequently. Will typically cause large log-files.	No direct reaction required. Used for problem analysis.

Exceptions (with their stack trace) should only be logged on FATAL or ERROR level. For business exceptions typically a WARNING including the message of the exception is sufficient.

Configure the active log levels per environment

When the application is executed on different environments it is a best practice to activate certain log levels depending on the type of the environment:

Log levels in different environments
Log-level	Active Environments
FATAL	all
ERROR	all
WARNING	all
INFO	all
DEBUG	development and testing
TRACE	none (turned off by default)

Use rolling log files

To prevent log file from getting to big it is a best practice to use rolling log files. This means that following a list of rules the logger will start logging to a new file. The frequency of the rolling depends on the amount of log message and on the file size the file system and the applications, used to view the logs, can handle.