Previously, if Jackson was on the classpath but no JsonMapper bean
was present, the app would fail to start. This commit updates
the auto-configuration so that the parts that require a JsonMapper
bean back of when no such bean is present.
The sample problem also exists with Jackson 2 and an ObjectMapper
bean. This commit also corrects that.
Fixes gh-49749
Previously, the absence of Jackson would result in the loss of
some configuration that does not depend on Jackson. That
configuration is:
- the inbound and outbound channels' executors
- the bean that forces the stompWebSocketHandlerMapping bean to be
eager when lazy init is enabled
This commit updates the auto-configuration so that only the Jackson
message converter configuration backs off in Jackson's absence.
Fixes gh-49750
Update `spring-boot-configuration-processor` to support method-level
`@NestedConfigurationProperty` annotations when constructor binding
is being used.
Fixes gh-49734
Update `ConfigDataEnvironment` to restore previous property override
behavior by correctly grouping the initial `ConfigDataContributor`
instances.
This regression was cause by the polish commit 646db448 which attempted
to simplify the fix for gh-49324 by including all initial contributors
in a single contributor node. This change inadvertently changed the
iteration order for the `spring.config.location` and
`spring.config.additional-location` properties which still need to
be expanded and added in reverse order.
Fixes gh-49724
* dependabot/github_actions/jfrog/setup-jfrog-cli-4.10.0:
Polish "Bump jfrog/setup-jfrog-cli from 4.9.1 to 4.10.0"
Bump jfrog/setup-jfrog-cli from 4.9.1 to 4.10.0
Closes gh-49718
* kotlin-examples-redux:
Polish "Add some more Kotlin examples and trivial style fixes"
Add some more Kotlin examples and trivial style fixes
Closes gh-49710
The Jackson team have ended support for Jackson 2.19.x (and 2.20.x).
In response to this, this commit upgrades to Jackson 2.21.2. 2.21.x
is designated as an LTS release so future minor upgrades should not
be necessary.
Closes gh-49365
Flyway's org.flywaydb.core.internal.scanner.Scanner does not make
any ordering guarantees so neither does our
NativeImageResourceProvider. It also isn't required by the contract
where a Collection is returned so we can relax the assertion in the
test so that it doesn't care about the ordering.
See gh-49661
Prior to this commit, the native image support for scanning Flyway
migration scripts would not scan sub-folders at runtime when running a
Native image.
This commit ensures that the resource scanning at runtime also considers
sub-directories for native images.
Fixes gh-49661