Where the Problem Started
Configuration problems fail more quietly than code. When a value appears to be set but behavior does not change, the real question is which configuration file is being read and in what order. This post follows Hibernate slow query logging and revisits Spring Boot configuration priority.
I tried to log slow database queries to the console.
I thought I might need to implement configuration around Hibernate or hikariCP, similar to an HTTP interceptor, at the moment a query is processed by the database, but it turned out to be simpler than expected.
Just add the following to application.properties:
Implementation Path
spring.jpa.properties.hibernate.generate_statistics=true
logging.level.org.hibernate=INFO
hibernate.session.events.log.LOG_QUERIES_SLOWER_THAN_MS=desired time in MS (greater than 0)Configuration Takeaway
Configuration is the hidden control plane of an application. Without understanding how YAML, properties, profile-specific files, and environment variables are merged, it is easy to change the same value repeatedly and still miss the cause. The check is not whether the setting exists, but whether it was actually bound.
If configuring it in yaml, same as always, change . to :.
Of course, there is no problem with separating logging levels or setting only the statistics-related logs to INFO.
But it does not log.
Just in case, I added these settings to the direct configuration file, hibernate.properties, instead of application.yaml, and confirmed that logging worked normally.
The important point is that Spring Boot does not provide a special rule for a project that mixes .yaml/.yml and .properties files for the same configuration surface.
The relevant behavior is documented here: https://docs.spring.io/spring-boot/docs/2.4.2/reference/htmlsingle/#boot-features-external-config.
The documentation specifies priority among config files, environment variables, and related sources, but I could not find an explicit precedence rule between .yaml and .properties formats. In testing, the .properties file in this case was read first.
Another thing worth noting is that application-{ENV}.yml is read before application.yml. In many projects, it is common to keep application.yml as shared configuration and define environments such as develop, release, and main separately, and the documentation confirms that this behavior is specified.