fix(logging): use one logback-spring.xml and silence logback status from main() - #193
Merged
Merged
Conversation
…rom main() Spring Boot expects a single logging configuration resolved by convention. Since apache#189 the repo shipped two (logback.xml holding only a NopStatusListener, logback-spring.xml holding the <springProfile> appenders) plus a logging.config property whose only purpose was to steer Boot past the first file, which initializeWithConventions() would otherwise stop at, never loading the -spring variant. A test existed solely to keep the three coupled. The early file did one job: install a status listener before Boot exists, so that logback's own initialization in a native image (where checkVersions() always raises a |-WARN) does not print its status list to stdout, corrupting the MCP STDIO stream. Logback's logback.statusListenerClass system property does exactly that: ContextInitializer.autoConfig() reads it in installIfAsked() after checkVersions(), and LogbackServiceProvider skips StatusPrinter.printInCaseOfErrorsOrWarnings() whenever a listener is installed. Main.main() now sets it as its first statement, unless an operator already set it on the command line. - delete logback.xml and the logback.xml native resource hint - drop logging.config from application.properties; LOGGING_CONFIG in the environment still overrides as Boot's normal external-file mechanism - LoggingConfigurationTest now pins the convention: no standard-location logback file on the classpath, no logging.config, and Main installs a listener StatusListenerConfigHelper honours - update AGENTS.md, the native-image dev doc, docs/security/stdio.md and the keycloak.md troubleshooting section that still described the pre-apache#189 state Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wh7SJkZhL1uuK7pYc3SLk8 Signed-off-by: Aditya Parikh <aditya.m.parikh@gmail.com>
Contributor
Author
|
Native verification done: |
Contributor
|
Fixing main! |
adityamparikh
added a commit
to adityamparikh/solr-mcp
that referenced
this pull request
Sep 11, 2026
Takes the single-logback-spring.xml convention from apache#193 and carries the Boot 4 empty-console-pattern fix across it: - AGENTS.md, docs/security/stdio.md: keep apache#193's wording but describe the empty logging.pattern.console as something the stdio profile must not set, with the Spring Framework 7 context-pausing rationale. - LoggingConfigurationTest moved to the top-level package in apache#193; the stdioProfileDoesNotExportAnEmptyConsolePattern guard is re-homed there and the old config/ copy is dropped. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HQhKFCmP75K71UV7CiYTqB Signed-off-by: Aditya Parikh <aditya.m.parikh@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
After #189 the logging setup had three coupled pieces and a test whose only job was to keep them coupled:
logback.xmlNopStatusListenerand nothing else, so logback's own pre-Spring init stays off stdout in the native imagelogback-spring.xml<springProfile>appenderslogging.config=classpath:logback-spring.xmlinapplication.propertieslogback.xml, whichinitializeWithConventions()would otherwise stop at, never loading the-springvariantThat is not how Boot expects to be configured. The reference documentation asks for one file, resolved by convention, and reserves
logging.configfor pointing at an external file. Two classpath files disambiguated by a property is a workaround, andLoggingConfigurationTestexisted to stop anyone from "cleaning it up" — which #104 had in fact done in a stray commit that would now break native STDIO.Change
The only thing
logback.xmldid was install a status listener before Boot exists. Logback has a first-class knob for exactly that, thelogback.statusListenerClasssystem property, and I verified the ordering in logback 1.5.32 (Boot 3.5.14's BOM):ContextInitializer.autoConfig()runscheckVersions()(the source of the native-only|-WARN), thenStatusListenerConfigHelper.installIfAsked()(reads the property), andLogbackServiceProvidercallsStatusPrinter.printInCaseOfErrorsOrWarnings()only whenStatusUtil.contextHasStatusListener()is false. So the listener does not need to exist before the WARN, only before the print, and the property is read in between.Main.main()sets the property as its first statement. An operator's explicit-Dlogback.statusListenerClass=...OnConsoleStatusListenerwins, so logback itself can still be debugged.logback.xmldeleted.logging.configremoved fromapplication.properties.LOGGING_CONFIGin the environment still works as Boot's normal override for an external file.SolrNativeHintsno longer registerslogback.xml; thelogback-spring.xmlhint stays as belt-and-braces for the non-AOT path.LoggingConfigurationTestnow pins the convention instead of the coupling: no standard-location logback file on the classpath, nologging.configinapplication.properties, andMaininstalls a listener thatStatusListenerConfigHelperhonours. Written first and watched fail onmainbefore the change.AGENTS.md,dev-docs/graalvm-native-image.md,docs/security/stdio.mdand thekeycloak.mdtroubleshooting section (which still described the pre-fix(logging): load logback-spring.xml without breaking native stdout #189 "no HTTP logs" state) updated.logging.pattern.console=inapplication-stdio.propertiesis untouched: it is the idiom Spring AI documents for STDIO servers and does not depend on any of the above.Verification
LoggingConfigurationTestonmainbefore the changelogback.xmlpresent,logging.configset), compile error for the missingMainAPI./gradlew build(JDK 25)McpClientStdioIntegrationTest(JVMjava -jarover MCP STDIO) 40/40./gradlew dockerIntegrationTest -Pnative(native STDIO image driven over MCP STDIO)solr-mcp:1.0.0-SNAPSHOT-native-stdio(GraalVM CE 25.0.2, Paketo):DockerImageMcpClientStdioIntegrationTest40/40,DockerImageStdioIntegrationTest4/4Related
logback.xmlremoval commit (777168e8) carried by fix(config): reject a solr.url SolrJ cannot connect to at bind time #104; that PR should drop the commit on its next rebase, since with this change there is nothing left to remove.🤖 Generated with Claude Code
https://claude.ai/code/session_01Wh7SJkZhL1uuK7pYc3SLk8