Add an 'sbom' command to the tools jar mode which prints the SBOM
packaged in an uber jar or war. The SBOM is located using the
Sbom-Location manifest attribute and its bytes are copied verbatim to
the console, or to the file given by --destination.
See gh-51505
Signed-off-by: Hyeongjun Cho <ryuu.public@gmail.com>
Update link DSL with a new `Links` type and an enum for the type
rather than a name. This update also fixes Hibernate links which were
broken.
See gh-51498
Replace the hand-rolled LdapContextSource of the embedded server
with an LdapConnectionDetails implementation, so that
LdapAutoConfiguration creates the context source for both the external
and the embedded case. Previously, the embedded context source derived
the URL scheme from spring.ldap.ssl and never applied an SSL bundle to
the JNDI environment, leaving an embedded LDAPS server unreachable. It
also ignored spring.ldap.anonymous-read-only, spring.ldap.referral,
spring.ldap.base-environment and any DirContextAuthenticationStrategy
bean, all of which now apply.
The embedded server provides everything that describes a connection to
it, so spring.ldap.urls, spring.ldap.username, spring.ldap.password and
spring.ldap.ssl are now ignored while it is used. A spring.ldap
configuration meant for a production server therefore no longer has to
be unset for a test to run against the embedded server. This is a
behavior change: spring.ldap.urls used to take precedence and silently
pointed the client away from the embedded server.
As spring.ldap.base-environment now applies to the embedded case, a
socket factory set there would be replaced by the one of the SSL
bundle. Startup fails instead of using either silently.
LdapProperties.determineUrls has been removed. Its local.ldap.port
handling only ever served the embedded case, which the embedded
connection details now cover, and the default URL derivation has moved
to PropertiesLdapConnectionDetails, its only caller.
Closes gh-51465
Setting spring.ldap.embedded.ssl.enabled without an SSL bundle started a
plain LDAP listener silently. It now fails at startup as a bundle is
required to provide the server's certificate and private key.
Closes gh-51471
Configure the SSL bundle through the context source's base environment
rather than a DirContextAuthenticationStrategy. The strategy is not
consulted when read-only operations use an anonymous environment,
which is the default when no username is set, so LDAPS connections
silently used the JVM's default trust material. It was also bypassed
entirely when a custom strategy bean was defined.
Register an SSL bundle update handler so that reloaded key and trust
material is used by subsequent connections.
Target LDAPS rather than StartTLS by setting the JNDI
java.naming.ldap.factory.socket property, and fail at startup if a
bundle is combined with a non-ldaps URL or with a socket factory that
has also been set through spring.ldap.base-environment. Delegate all
socket factory methods so that a configured connect timeout is
applied.
Add spring.ldap.ssl.enabled to use the platform's default trust and
key material without a bundle, default the URL to
ldaps://localhost:636 when SSL is enabled, and register the reflection
hint that JNDI needs to load the socket factory by name in a native
image. Cover the result with integration tests that search over LDAPS
against OpenLDAP and LLDAP containers, including certificates that are
untrusted or issued to a different host.
See gh-51382
Derive logging.pattern.correlation from the configured MDC keys so that
log correlation keeps working when the keys are customized, instead of
silently rendering a blank correlation field.
Reject empty MDC keys and only clear Brave's default correlation fields
when the keys have been customized, so that applications using the
defaults are unaffected if Brave adds a default field.
Replace the tests that asserted on bean wiring with integration tests
covering the MDC contents, plus a smoke test for the log output.
See gh-50595
Servlet web security moved to ServletWebSecurityAutoConfiguration, but
the MVC Security section still describes SecurityAutoConfiguration
importing SpringBootWebSecurityConfiguration, which no longer exists.
See gh-51411
Signed-off-by: Alexander Makarov <alexander.makarov@nightsong.li>
The auto-configuration for the InfluxDB client was removed in 3.4.0, but
the NoSQL section of the reference documentation still described it.
See gh-51172
Signed-off-by: Alexander Makarov <alexander.makarov@nightsong.li>
This commit introduces new properties for configuring the HTTP headers
that should be used for forward support.
The new `server.netty.forwarded-headers.header-format` property allows
"standard" or "x_forwarded" to select "Forwarded" or "X-Forwarded-*"
headers.
This aligns the behavior of Netty server with the "FRAMEWORK" strategy.
Closes gh-51031
This commit introduces new properties for configuring the HTTP headers
that should be used for forward support.
The new `server.jetty.forwarded-headers.header-format` property allows
"standard" or "x_forwarded" to select "Forwarded" or "X-Forwarded-*"
headers.
This aligns the behavior of Jetty server with the "FRAMEWORK" strategy.
Closes gh-51148
Prior to this commit, Spring Boot would auto-configure the
`ForwardedHeaderFilter`/`ForwardedHeaderTransformer` when the "NATIVE"
strategy is chosen.
Spring Framework now requires an explicit choice between the supported
HTTP header variants as of spring-projects/spring-framework#37072.
This commit adapts to this new behavior with the following:
* the "FRAMEWORK" strategy now only applies to Spring MVC and Spring
WebFlux applications, since "NATIVE" strategies are now a good choice
for most deployments.
* the format of HTTP headers is now configured with
`spring.mvc.forwarded-headers.header-format` and
`spring.webflux.forwarded-headers.header-format`, with additional
options.
The default header format is now "X-Forwarded-*" for both NATIVE and
FRAMEWORK strategies. The reference documentation also reflects those
changes.
Closes gh-51030
With Spring Framework 7.1 deprecating RestTemplate for removal, this
commit deprecates our supporting infrastructure as well, and steers
users towards RestClient instead:
* RestTemplateAutoConfiguration and
RestTemplateObservationAutoConfiguration
* RestTemplateBuilder, RestTemplateBuilderConfigurer, and
RestTemplateBuilderClientHttpRequestInitializer
* RestTemplateCustomizer, RestTemplateRequestCustomizer, and
ObservationRestTemplateCustomizer
* MockRestServiceServerAutoConfiguration,
MockServerRestTemplateCustomizer, and RootUriRequestExpectationManager
in the test support module
The reference documentation no longer covers RestTemplate and now
solely documents RestClient and WebClient. Code snippets and sample
tests that only existed to illustrate RestTemplate usage have been
removed accordingly.
Closes gh-51118
Hyeongjun Cho
henriquejsza
Phillip Webb
Moritz Halbritter
chisanw
Alexander Makarov
Stéphane Nicoll
Brian Clozel
wantaek