codeconsole opened a new pull request, #15757:
URL: https://github.com/apache/grails-core/pull/15757
## Summary
Removes `grails-app/conf/logback-spring.xml` from the **base profile
skeleton**
(`grails-profiles/base/skeleton/grails-app/conf/logback-spring.xml`) so it
is no
longer scaffolded into every newly created Grails application.
Logging continues to work with zero configuration, because the base profile
already declares `spring-boot-starter-logging` (see
`grails-profiles/base/profile.yml`). That puts Logback **and Spring Boot's
own
default Logback configuration** on the classpath, which Boot applies
automatically whenever the app does not supply its own config. The generated
file is therefore not required — and, as shown below, it actively works
against
Spring Boot 4.x conventions.
## Why this file should not be created automatically
### 1. Spring Boot already provides a complete default configuration
When `spring-boot-starter-logging` is present and **no** user config is
found,
Spring Boot loads its bundled Logback setup from the `spring-boot` jar:
- `org/springframework/boot/logging/logback/base.xml` — top-level wiring
- `…/defaults.xml` — default levels and conversion rules
- `…/console-appender.xml` — the standard console pattern (with ANSI color
when
the console supports it)
- `…/file-appender.xml` — activated only when `logging.file.name` /
`logging.file.path` is set
This is the explicit, documented "it just works with zero config" contract of
Spring Boot. Shipping a hand-written `logback-spring.xml` in the skeleton
*opts every new app out of that contract on day one* and replaces a
well-maintained, version-matched default with a static file we now have to
keep
in sync with Boot ourselves.
### 2. The file we ship degrades the out-of-the-box defaults
The current skeleton file (39 lines) does three things that surprise users:
```xml
<root level="ERROR">
<appender-ref ref="CONSOLE"/>
</root>
```
- **Forces the root level to `ERROR`.** Spring Boot's default is `INFO`. With
our file, a brand-new app silently swallows all `WARN` and `INFO` output —
including framework startup warnings and the kind of logging developers
expect to see while building. This is one of the most common "why isn't my
app logging anything?" papercuts.
- **Hard-codes `withJansi=false`** on the console appender, opting every new
app out of the ANSI coloring Boot enables automatically on capable
terminals.
- **Is mostly commented-out boilerplate** — a file appender block and sample
loggers (`org.hibernate.SQL`, `org.springframework.security`, …) that are
all
disabled. A freshly generated project starts life with a config file that
is
~70% dead, commented code.
None of this is configuration a new project needs. It is configuration a new
project has to *understand and undo*.
### 3. It matches the Spring Boot 4.x convention
The modern Spring Boot convention (and what `start.spring.io` produces) is to
ship **no logging config file at all**. A generated Spring Boot 4.x app has
an
empty-by-default `src/main/resources/application.{yml,properties}` and
relies on
Boot's defaults; you add a `logback-spring.xml` only when you genuinely need
to
customize. Removing this file brings Grails app generation in line with that
convention and with what Spring/Boot developers already expect.
### 4. Nothing depends on the file existing
The only in-repo references to `grails-app/conf/logback-spring.xml` are
documentation that describes it as a place you *can* configure logging — not
a
file that must be present. No build step, test, or profile manifest
enumerates
or asserts it (`profile.yml` copies the skeleton directory wholesale; it does
not reference individual files). Removing it is a clean deletion.
> Note / out of scope: the newer **Grails Forge** generator emits its own
> `logback-spring.xml` from a separate Rocker template
> (`grails-forge/.../feature/logging/Logback.java`,
> `logback.rocker.raw`). This PR intentionally scopes to the profile
skeleton —
> the "create-app" starter template — to keep the change focused. If the
project
> agrees with the direction, aligning Forge's `Logback` feature is a sensible
> follow-up.
## Best practices: configuring logging in Grails 8 / Spring Boot 4.x
With this change, the recommended workflow for a new app is:
**1. Do nothing — logging already works.** Boot's defaults give you an INFO
root
logger and a colorized console pattern with no files to manage.
**2. Tune levels and patterns from `application.yml`** (no XML required):
```yaml
logging:
level:
root: INFO
com.example.myapp: DEBUG # your packages
org.springframework.web: DEBUG # framework packages
org.hibernate.SQL: DEBUG # see generated SQL
pattern:
console: "%d{HH:mm:ss.SSS} %-5level %logger{36} - %msg%n"
file:
name: logs/myapp.log # setting this activates Boot's file
appender
```
**3. Add a config file only when properties aren't enough** — custom
appenders,
JSON/structured output, per-profile routing, etc. When you do, create
**`grails-app/conf/logback-spring.xml`** (the `-spring` variant, *not* plain
`logback.xml`), because it is processed by Boot and unlocks
`<springProfile>` and `<springProperty>`. A minimal, *additive* file that
builds
on the defaults rather than replacing them:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<!-- inherit Boot's console appender, pattern and conversion rules -->
<include resource="org/springframework/boot/logging/logback/base.xml"/>
<!-- environment-specific tweaks, layered on top of the defaults -->
<springProfile name="development">
<logger name="org.hibernate.SQL" level="DEBUG"/>
</springProfile>
</configuration>
```
**4. Keep environment-specific logging in `<springProfile>` blocks** so a
single
file serves dev / test / prod, driven by the active Spring profile.
The guiding principle is the Spring Boot one: **start from zero config, add
only
the delta you need, and build on Boot's defaults instead of overriding
them.**
## Test plan
- `git rm` of a single skeleton resource; no source, build, or test code
changes.
- Generating an app from the base profile no longer produces
`grails-app/conf/logback-spring.xml`; the app starts and logs via Spring
Boot's default Logback configuration (INFO root, colorized console).
- Adding `logging.level.*` to `application.yml` adjusts levels as expected
with
no XML present.
---
https://claude.ai/code/session_01XEzHYeRE8xAg8hE3M2WJF3
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
