Updates Compatible with SpringBoot 1.x that are required for Springboot 3.x and not handled by /transform #14
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.
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:
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:
The Correct Pattern (Always Valid)
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: