-
Notifications
You must be signed in to change notification settings - Fork 631
Description
Describe the issue
Derived of this issue, In Spring Cloud Stream 4.3.0 (included in Spring Cloud 2025.0.0), a banner.txt file was added as a resource in the default location where Spring Boot searches for application banners. This creates two potential issues:
-
Banner Location Conflict: When applications have their own
banner.txtfile in the default location (src/main/resources/), there's unpredictable behavior regarding which banner is displayed at startup. The ClassLoader may find either the Spring Cloud Stream banner or the application's banner first, making the outcome non-deterministic. -
Unnecessary Performance Impact: The
VersionExtractorEnvironmentPostProcessor always scans JARs to extract and set thespring-cloud-function.versionsystem property for display in the Spring Cloud Stream banner, even when applications want to use their custom banner and don't need this version information.
To Reproduce
- Create a Spring Boot application with Spring Cloud Stream 4.3.0+ dependency
- Add a custom
banner.txtfile insrc/main/resources/(default location) - Run the application
- Observe non-deterministic behavior: sometimes the Spring Cloud Stream banner appears, sometimes the custom banner appears
Version of the framework
- Spring Boot: 3.5.6
- Spring Cloud: 2025.0.0
- Spring Cloud Stream: 4.3.0
Expected behavior
-
Banner Predictability: Applications should have control over which banner is displayed, or there should be a clear precedence order that doesn't rely on ClassLoader order.
-
Optional Version Processing: There should be a configuration property to disable the
VersionExtractorprocessing when applications don't need thespring-cloud-function.versionsystem property, avoiding unnecessary JAR scanning and potential startup performance penalties.
Your considerations in this regard will be greatly appreciated! Thank you!