Module io.jstach.rainbowgum.spring.boot4

module io.jstach.rainbowgum.spring.boot4
Rainbow Gum Spring Boot 4 integration.

Both the module name and the io.jstach.rainbowgum.spring.boot4 package are suffixed with the Spring Boot major version because this module's code is duplicated (not shared) with io.jstach.rainbowgum.spring.boot3: none of it is exported, all of it is wired up internally through provides/uses or Spring Boot's own META-INF/spring.factories, so no consumer ever imports it directly and there is no "drop-in" benefit to giving the two modules' internals the same package name - unlike two modules ever sharing a module name, which is a hard JPMS conflict the moment both are combined onto one module graph, as this repository's own aggregate javadoc build does. The SPI package (io.jstach.rainbowgum.spring.boot.spi) lives in its own genuinely shared module, io.jstach.rainbowgum.spring.boot.spi, since it does not depend on Spring Boot at all (just the stable Environment type from spring-core) and is meant to be implemented by consumers, so it is neither duplicated nor suffixed.

Spring Boot logging property support - see Spring Boot's own logging documentation for what each property means. This is a snapshot of Boot 4 support specifically; the (separately maintained, not necessarily identical) Boot 3 module is io.jstach.rainbowgum.spring.boot3. Every property key below is a {@value} reference into SpringBootSupportedProperties (or, for the two properties RainbowGum core itself understands independent of Spring Boot, LogProperties) rather than a literal string, so this table can't silently drift from what the code actually reads.

Supported
Property Notes
"logging.level.root", logging.level.<logger>, "logging.group.{name}" Native - the group property works because RainbowGum core's own GroupLevelResolver already uses this exact property key, not anything Spring-specific.
debug, trace Transitively - Spring's own LoggingApplicationListener converts these to "logging.level.root" before any LoggingSystem is initialized.
"logging.pattern.console", "logging.pattern.file", "logging.pattern.level", "logging.pattern.dateformat", "logging.exception-conversion-word" Transitively - Spring Boot bridges these to system properties (CONSOLE_LOG_PATTERN, etc.) before calling initialize(); this module's Patterns class reads those system properties, the same mechanism a hand-written logback.xml would rely on.
"logging.include-application-name", "logging.include-application-group" Native - toggle whether the default pattern includes those segments.
"logging.file.name" Native, but in rainbowgum-core itself (not this module) - works even without Spring Boot on the classpath at all, kept there for that reason.
"logging.file.path" Native - synthesizes <path>/spring.log when logging.file.name itself is unset, matching Spring Boot's own LogFile.get(...) precedence.
"logging.console.enabled" Native - when false, restricts the route to just the file appender if one resolves; otherwise left alone rather than pointing at nothing.
"spring.output.ansi.enabled" ( NEVER/ALWAYS/DETECT) Native - bridged to RainbowGum's own existing logging.global.ansi.disable property rather than a second ansi mechanism; DETECT (or unset) leaves RainbowGum's own auto-detection in charge.
"logging.structured.format.console", "logging.structured.format.file" ( ecs/gelf/logstash only - not a custom StructuredLogFormatter class name) Native - bridges to rainbowgum-json's EcsEncoder/ GelfEncoder/LogstashEncoder. The two properties are independent, matching Spring Boot's own behavior.
"logging.structured.ecs.service.name", "logging.structured.ecs.service.version", "logging.structured.ecs.service.environment", "logging.structured.ecs.service.node-name" Native - .name/.version default to spring.application.name/.version the same way Spring Boot's own ECS formatter does.
"logging.structured.gelf.host", "logging.structured.gelf.service.version" Native - .host defaults to spring.application.name. GELF has no dedicated version field, so .service.version becomes an underscore-prefixed _service_version additional field, matching Spring Boot's own GELF formatter's naming.
"logging.charset.console", "logging.charset.file" Native - bridged to the pattern encoder's own charset builder property (a core rainbowgum-pattern capability, not Spring-specific); unset falls back to UTF-8 the same as when Spring Boot is not on the classpath at all.
Not supported
Property Why
logging.threshold.console, logging.threshold.file Would need a new core capability (per-appender level filtering within a multi-appender route - level filtering today is per-route, not per-appender).
logging.structured.json.include, .exclude, .rename.*, .add.*, .customizer, .stacktrace.* Spring Boot's own JsonWriter/StackTracePrinter customization layer, specific to its StructuredLogFormatter machinery - no RainbowGum equivalent to bridge to.
A fully-qualified StructuredLogFormatter class name as the logging.structured.format.* value (Spring Boot's fully-custom-format escape hatch) No RainbowGum equivalent; silently falls back to whatever pattern encoder is already installed for that output type rather than failing.
logging.config No RainbowGum equivalent - configuration is property-driven, not a separate config file format like logback.xml.
logging.register-shutdown-hook Unclear mapping to RainbowGum's own shutdown lifecycle - not attempted.
logging.logback.rollingpolicy.*, logging.log4j2.rollingpolicy.* N/A - this module has no Logback or Log4j2 dependency, and RainbowGum does not support file rolling at all (see the roadmap's file-rolling discussion).