Skip to content

Conversation

@briananderson1222
Copy link

Issue #, if available: #13

Description of changes:

The Change in Logback Configuration (5bdca3a)

The issue wasn't actually a change in logback's XML schema itself, but rather how Spring Boot handles and validates logback configurations became more strict over time.

What Was Happening Before (Spring Boot 1.x)

In Spring Boot 1.2.3 (released in 2015), the logback configuration parsing was more lenient:
• Invalid or malformed configurations would often be silently ignored
• Spring Boot's logback integration was less strict about proper XML structure
• The application would still start even with configuration errors, often falling back to default console logging

What Changed (Spring Boot 2.x and 3.x Evolution)

The stricter validation was introduced gradually:

Spring Boot 2.0+ (2018):
• Introduced more robust configuration validation
• Better error reporting for malformed configurations
• Stricter adherence to logback's XML schema

Spring Boot 2.4+ (2020):
• Enhanced logback integration with better parsing
• More detailed warning messages for configuration issues

Spring Boot 3.x (2022+):
• Even stricter validation as part of the Jakarta EE migration
• Configuration errors that were previously ignored now cause startup failures
• Better integration with logback's native configuration validation

The Specific Issue in Your Configuration

Your original configuration had this invalid structure:

<root level="DEBUG">
    <appender name="console-appender" class="ch.qos.logback.core.ConsoleAppender">
        <!-- configuration -->
    </appender>
</root>

Why this was wrong: In logback's XML schema, appenders must be defined at the level, not inside or elements. The element should only contain elements to reference pre-defined
appenders.

Timeline of When This Became Critical

Spring Boot 1.x: Your malformed config worked (or appeared to work) due to lenient parsing
Spring Boot 2.1+: Started showing warnings like "Appender named [console-appender] not referenced"
Spring Boot 2.4+: More aggressive validation, but still might start with fallback logging
Spring Boot 3.x: Strict validation causes the application to hang/fail during logging system initialization

Why Your App "Froze"

In Spring Boot 3.2.3, when logback encounters the malformed configuration:

  1. It tries to parse the XML during application startup
  2. The invalid appender definition causes the logging system initialization to fail
  3. Since logging is critical for Spring Boot's startup process, the application hangs waiting for the logging system to initialize
  4. No error messages appear because the logging system itself is broken

The Correct Pattern (Always Valid)

<configuration>
    <!-- Define appenders at configuration level -->
    <appender name="console-appender" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{HH:mm:ss.SSS} | %thread | %-5level | %logger{1} | %msg%n</pattern>
        </encoder>
    </appender>
    
    <!-- Reference appenders in loggers -->
    <root level="DEBUG">
        <appender-ref ref="console-appender"/>
    </root>
</configuration>

This pattern has been the correct logback configuration since logback's early versions, but Spring Boot's enforcement of it became much stricter during your migration window.

Additional problem with reflection and parameter name resolution (31eacbe)

The Issue in Migration Context

Java 8 + Spring Boot 1.x: Parameter names were often inferred or handled more leniently
Java 21 + Spring Boot 3.x: Stricter parameter name resolution, requires either:

  1. Explicit annotation names, OR
  2. Compiler -parameters flag to preserve parameter names in bytecode

Brian Anderson added 2 commits June 12, 2025 09:20
…-boot are more strict in their parsing and the /transform process doesn't seem to address this during the upgrade
… stricter requirements around reflection in more recent versions of Java
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant