codeconsole commented on PR #15757:
URL: https://github.com/apache/grails-core/pull/15757#issuecomment-4813057631
@jamesfredley Completely agree env-specific logging is expected and we must
not regress it — which is exactly why I didn't want to settle this from "a
quick round with AI." I tested it on Grails 8 (Spring Boot 4): generated an
app, booted it in `development`, and checked the **effective** level of loggers
configured three different ways.
| Mechanism | Result in `development` |
|---|---|
| `environments: development: logging.level…` in `application.yml` | ✅
applied |
| `application-development.yml` with `logging.level…` | ✅ applied |
| `logback-spring.xml` `<springProfile name="development">` | ✅ applied
(still works under Spring Boot 4) |
Two takeaways:
1. **`<springProfile>` still works in Grails 8 / Spring Boot 4** — this is
not a repeat of the Logback-killed-Groovy-config situation; nothing regressed.
2. **Environment-specific log _levels_ don't require `logback-spring.xml` at
all.** The Grails `environments` block in `application.yml` — which every app
already has — drives per-environment levels with zero XML. `logback-spring.xml`
is still the answer for env-specific *appenders* / patterns, which properties
can't express.
Given that, I'd argue *against* generating a replacement file. The old
generated `logback-spring.xml` was largely commented-out placeholders, and
seeding any "default" env logging is just config a new app has to read and undo
— the same papercut the PR is removing. So instead of shipping a file:
- Logging works out of the box (Spring Boot defaults), and **env-specific
logging is fully available with no file** — e.g. dev-verbose for your own
package:
```yaml
environments:
development:
logging:
level:
com.example: DEBUG
```
- For anyone who wants the XML / `<springProfile>` route (custom appenders,
structured output), the PR adds an opt-in **Logback Configuration** feature in
Forge that generates a starter `logback-spring.xml`.
- The upgrade guide and logging reference now document all of this.
Does that address the concern? If you'd still prefer a generated app to
*demonstrate* env logging, we could seed a **commented**
`environments`/`logging.level` example rather than active config — though I
lean against shipping anything the user didn't ask for.
--
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]
