skip to content

Spring Boot ships two predefined log groups. Which are they, and what would logging.level.sql=DEBUG turn on?

level: middleimportance: should knowfreq 40%

answer

  1. predefined groups: web + sql
  2. web = codec/http/web + actuator web + servlet init
  3. sql = jdbc.core + hibernate.SQL + jooq LoggerListener
  4. sql=DEBUG shows statements, not params
  5. params: hibernate.orm.jdbc.bind=TRACE (H6)

basics

~10 s

The predefined groups are web and sql. logging.level.sql=DEBUG raises the SQL-related loggers — Spring JDBC core, Hibernate's SQL logger, and jOOQ's logger listener — so you can see executed SQL without listing each package.

solid answer

~40 s

Spring Boot predefines two groups so you can use them without declaring them: web and sql. The web group covers the Spring web/HTTP stack — org.springframework.core.codec, org.springframework.http, org.springframework.web, plus the Boot actuator web endpoint and servlet initializer loggers. The sql group covers org.springframework.jdbc.core, org.hibernate.SQL, and org.jooq.tools.LoggerListener. So logging.level.sql=DEBUG is a one-line way to surface SQL activity from whichever of those you use — for JPA/Hibernate apps it turns on org.hibernate.SQL so statements are logged. Note that seeing bound parameter values usually needs an additional logger (e.g. org.hibernate.orm.jdbc.bind at TRACE on Hibernate 6), which is not part of the group. These groups are just convenient aliases; you can still target individual packages when you need finer control.

go deeper

for a junior

Knows web and sql exist as handy toggles.

for a middle

Names the groups and knows sql=DEBUG surfaces SQL statements.

for a senior

Distinguishes statement logging from parameter binding and knows the extra logger needed for params.

for a principal

Treats these as controlled, temporary debugging switches with data-leak and volume implications; prefers proper loggers over show-sql.

## The two predefined groups Spring Boot registers two log groups automatically, so `logging.level.web` and `logging.level.sql` work with no `logging.group.*` declaration of your own. ### `web` Members (the Spring web/HTTP stack): - `org.springframework.core.codec` - `org.springframework.http` - `org.springframework.web` - `org.springframework.boot.actuate.endpoint.web` - `org.springframework.boot.web.servlet.ServletContextInitializerBeans` Setting `logging.level.web=DEBUG` is a common way to see request mapping, content negotiation, and HTTP message conversion detail during debugging. ### `sql` Members (the SQL-related loggers across common data stacks): - `org.springframework.jdbc.core` — Spring's `JdbcTemplate`/core JDBC. - `org.hibernate.SQL` — Hibernate's logger that prints the SQL it executes. - `org.jooq.tools.LoggerListener` — jOOQ's query logging. `logging.level.sql=DEBUG` therefore turns on SQL statement logging from whichever of these libraries is on the classpath and in use. ## What sql=DEBUG does and does not show - **Does**: log the SQL statements themselves (e.g. Hibernate's `org.hibernate.SQL` at DEBUG prints each statement). - **Does not** (by itself): show the **bound parameter values**. On Hibernate 6+ those come from the logger `org.hibernate.orm.jdbc.bind` at TRACE; on older Hibernate it was `org.hibernate.type.descriptor.sql` at TRACE. These are not members of the `sql` group, so you add them separately. - Related but different: `spring.jpa.show-sql=true` prints SQL to stdout via Hibernate's own flag (not routed through the logging system), which is why relying on the `sql` group + a proper logger is preferred over `show-sql` in real apps. ## Why these groups exist They encode the fact that "the web layer" or "SQL" spans multiple packages/libraries. An operator can flip one toggle instead of memorising the member list, and the same alias works whether you set it via properties or change it at runtime. ## Gotchas - The `sql` group only helps for libraries you actually use; if you are on plain JDBC via `JdbcTemplate`, `org.hibernate.SQL` simply has nothing to emit. - Turning `web` or `sql` to DEBUG/TRACE in production is verbose and can leak data (SQL, headers) — treat as a temporary debugging switch. - Because these are predefined, redefining `logging.group.web`/`logging.group.sql` yourself overrides the built-in member list.

  • logging.level.sql=DEBUG shows the SQL but you also want the bound parameter values. How?
    The sql group logs statements, not parameters. Add a separate logger — on Hibernate 6 set logging.level.org.hibernate.orm.jdbc.bind=TRACE (older Hibernate: org.hibernate.type.descriptor.sql=TRACE).
  • Can you override what the built-in web group contains?
    Yes. Declaring your own logging.group.web=... replaces the predefined member list with yours, so you can add or remove packages.

saying these in an interview costs you the question

  • Claiming there are no predefined groups.
  • Saying logging.level.sql=DEBUG also prints bound parameter values (it does not — that needs a separate logger).
  • Confusing spring.jpa.show-sql with the sql log group (show-sql is a Hibernate stdout flag, not routed through logging levels).
  • Listing arbitrary packages as web-group members without knowing the actual set.

context

resolving links…