* pr/46974:
Polish "Create service connections for image with registry host and without project"
Create service connections for image with registry host and without project
Closes gh-46974
Spring Boot 4 requires Jakarta EE 11. Jersey 4 will support EE 11 but
its release schedule is uncertain. Furthermore, Jersey does not yet
support Jackson 3 and there's no clear timeline for when Jackson 3
will be supported.
In light of the above, this commit removes support for Jersey.
Reinstating support can be considered once there's a Jersey GA that
supports Jakarta EE 11 or its clear that one will be available in
time for Boot's GA in November. Ideally, support for Jackson 3 would
also be available before reinstating Jersey support.
Closes gh-47017
The resource resolver in DevTools can cause performance degradation
during application restarts in large projects. Key methods like
isDeleted() and getAdditionalResources() rely on nested loops, leading
to O(n*m) complexity.
This commit refactors ClassLoaderFiles to use a pre-computed, flattened
map. This provides O(1) complexity for direct lookups and allows for
efficient single-loop iteration.
The ClassLoaderFilesResourcePatternResolver is updated to leverage this
new, efficient structure:
- getFile() and size() are improved from O(n) to O(1).
- isDeleted() and getAdditionalResources() are improved from O(n*m) to
O(m) by eliminating nested loops.
- Data consistency is maintained across all operations.
This optimization significantly improves restart performance with a
minimal memory footprint, while preserving the existing API and
exception handling behavior.
See gh-46289
Signed-off-by: DongHoon Lee <dhl1924@naver.com>
Log4j Core 3 has undergone significant modularization and no longer uses
optional parser dependencies. This change requires updates to
Spring Boot's configuration file detection logic to properly support
both Log4j Core 2 and 3.
**Updated configuration file detection**
Spring Boot now detects configuration formats based on the presence of
ConfigurationFactory implementations, instead of relying on optional
parser dependencies (as was the case in Log4j Core 2).
**Improved classloader usage for reflection**
Reflection logic now uses the classloader that loaded Log4j Core,
rather than the one associated with the Spring Boot context,
ensuring greater compatibility in modular environments.
* **Adjusted configuration file lookup order**
The lookup now prioritizes configuration files specified via
properties over automatically discovered ones, improving consistency
with Log4j Core.
**Support for contextual configuration files**
Files named in the form `log4j2<contextName>.<extension>` are now also
supported.
These changes ensure compatibility with Log4j Core 3 while preserving
support for Log4j Core 2, improving Spring Boot's flexibility in
detecting and loading user-defined logging configurations.
See gh-46409
Signed-off-by: Piotr P. Karwasz <piotr@github.copernik.eu>