codeconsole commented on PR #15757:
URL: https://github.com/apache/grails-core/pull/15757#issuecomment-4949195581
@jamesfredley before this goes further I want to take each concern you've
raised head-on, with working configuration for every behavior you've said
requires `logback-spring.xml`. The short version: every expectation you've
named is met with zero XML, and the one capability that genuinely requires the
file is something the generated file never actually configured.
### 1. "Environment/spring profile specific logging is only possible via
`logback-spring.xml`"
This is the factual crux, and it's not correct — I verified it earlier in
this thread on a generated Grails 8 app (Spring Boot 4) by checking
**effective** logger levels at boot. Grails environments map to Spring
profiles, so per-environment logging works three ways, two of them with no XML:
```yaml
# grails-app/conf/application.yml — the environments block every Grails app
already has
environments:
development:
logging:
level:
com.example.myapp: DEBUG
```
```yaml
# grails-app/conf/application-development.yml — profile-specific config,
same effect
logging:
level:
com.example.myapp: DEBUG
```
And `<springProfile>` in a `logback-spring.xml` still works under Spring
Boot 4 if the file is added — nothing regressed. All three were ✅ in the table
above.
### 2. "having more detailed logs in dev is expected behavior and having
less detailed logs in prod is also"
Agreed — and here it is, complete, in the config format every Grails
developer already uses daily:
```yaml
environments:
development:
logging:
level:
com.example.myapp: DEBUG
org.hibernate.SQL: DEBUG
production:
logging:
level:
root: WARN
```
Dev verbose, prod quiet, per-environment, zero XML. This is not a
workaround; it's the same Spring Boot property surface the docs in this PR now
cover end to end (levels, patterns, logger groups, per-appender thresholds,
file output + rotation, `debug:`/`trace:` shortcuts).
### 3. "continuing to generate a logback-spring.xml that provides the same
historical environment specific logging, low default level in dev, as expected"
The historical file never provided that. Here is what it actually shipped,
verbatim:
```xml
<root level="ERROR"> <!-- applied to EVERY environment, including
development -->
<appender-ref ref="CONSOLE"/>
</root>
<springProfile name="development">
<logger name="StackTrace" level="ERROR" />
<!-- every other logger in this block was commented out -->
</springProfile>
```
Out of the box, the historical file gave a new developer **ERROR-only
logging in development** — it suppressed all WARN and INFO output, including
framework startup warnings. That is *less* dev logging than Spring Boot's
zero-config default (INFO root, colorized console) provides. The "excellent out
of the box experience" you're defending is one where a new user's first
question is "why isn't my app logging anything?" — the exact papercut #15973
just had to fix. If historical expected behavior is the standard, the file
fails it and the Boot default exceeds it.
### 4. "There were so many tickets when Logback nuked the groovy config and
I don't want us back in that situation"
That situation was a **capability removal**: `logback.groovy` stopped
working and there was no equivalent. Nothing here stops working.
`logback-spring.xml` with `<springProfile>` remains fully supported,
documented, and testable — this PR only stops scaffolding a file into
applications that don't need one. The recovery path is one click (the *Logback
Configuration* Forge feature) or copying the documented snippet, and both the
upgrade guide and the logging reference now spell it out. There is no lost
capability for anyone to file a ticket about.
### 5. "I don't think that is the majority use case for generated apps on
forge, which in theory are greenfield"
Greenfield is precisely where zero-config is the right default. A greenfield
app has no custom appenders, no structured output pipeline, no per-environment
routing — it needs sensible levels and a readable console, which Boot's
defaults provide with no file to read, understand, or undo. This is also what
every greenfield Spring Boot app gets: `start.spring.io` ships **no logging
config file at all**, and Grails 8 is a Spring Boot 4 framework. A
majority-of-users argument favors the convention the surrounding ecosystem has
already settled on — and the users who *do* want the XML file are exactly the
ones capable of ticking a clearly named Forge feature.
### What actually requires the file
One thing: `<springProfile>`-conditional **appenders/routing** (e.g., JSON
appender in prod only). Per-environment *levels* — which is what "detailed in
dev, quiet in prod" means — do not need it. And note: the generated file never
configured a single environment-specific appender; that section was entirely
commented out. So removing the file takes away nothing any generated app ever
had — while the opt-in feature and the docs cover the real XML use case better
than the old boilerplate did.
Given that every expectation raised here is demonstrably met without the
file, and the historical file demonstrably did not deliver the dev experience
being cited in its defense, I think the default should stay off. Happy to walk
through any of the examples above on a live generated app.
--
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]
