The spring.http.clients.cookie-handling property and
HttpClientSettings.cookieHandling() were honored by every imperative
ClientHttpRequestFactoryBuilder and by the Jetty, JDK and Reactor
ClientHttpConnectorBuilders, but HttpComponentsHttpAsyncClientBuilder
ignored the setting. As a result, a WebClient backed by Apache
HttpComponents kept storing cookies even when cookie handling was
disabled.
Map the setting to the default request config's cookie spec, as
HttpComponentsHttpClientBuilder already does, and document the property
alongside the other global HTTP client settings.
See gh-51724
Signed-off-by: Hyun Lee <dlwhdugs4147@gmail.com>
Update `NestedJarFileResources` to fix a race condition that could
result in a `NullPointerException`.
The methods `getOrCreateInflater` and `endOrCacheInflater` both
synchronize on a local `inflaterCache` variable but attempted to use the
`this.inflaterCache` instance which could be set to null.
The `releaseInflators` method had a synchronized block for ending each
inflater but the cache was being nulled out outside the block meaning that
the other 2 methods mentioned could hit the race condition.
Signed-off-by: Ian Kettle <25729118+icikle@users.noreply.github.com>
See gh-51744
Closes gh-51708
* fix-devtools-reactive-web-environment-detection:
Polish "Fix detection of reactive web environments in DevTools"
Fix detection of reactive web environments in DevTools
DevToolsPropertyDefaultsPostProcessor looked for
ConfigurableReactiveWebEnvironment
in org.springframework.boot.web.reactive.context by name, but the class
moved to org.springframework.boot.web.context.reactive in 4.0. As a
result, reactive web applications were never identified as web
applications and the hint about setting logging.level.web to DEBUG was
not logged for them.
ConfigurableReactiveWebEnvironment is part of spring-boot, so it is now
referenced directly rather than by name. The servlet environment check
is unchanged as spring-web is an optional dependency.
See gh-51708
Signed-off-by: ohchanKyu <okc0202@naver.com>
The default of @AutoConfigureTestDatabase's replace attribute changed
from ANY to NON_TEST in 3.4 but the manually declared metadata for
spring.test.database.replace still advertised "any" as the default.
See gh-51709
Signed-off-by: ohchanKyu <okc0202@naver.com>
Closes gh-51666
* gh-51666:
Polish "Use TLS port for Docker Compose RabbitMQ connection when SSL is configured"
Use TLS port for Docker Compose RabbitMQ connection when SSL is configured
When a rabbitmq Docker Compose service has SSL bundle labels,
RabbitDockerComposeConnectionDetailsFactory created an SslBundle but
still resolved the address from container port 5672, the plain AMQP
listener. As the connection factory enables SSL when an SslBundle is
present, the TLS handshake was attempted against the non-TLS listener
and the connection failed.
The address is now resolved from container port 5671 when an SslBundle
is present, matching RabbitStreamDockerComposeConnectionDetailsFactory
and the Testcontainers-based RabbitContainerConnectionDetailsFactory.
The SSL integration test now opens a connection using the resolved
address and SslBundle so that it fails without this fix.
Signed-off-by: ohchanKyu <okc0202@naver.com>
See gh-51666
Changelog.computeDifferences() called
ConfigurationMetadataRepository.getAllProperties() from inside its main
loop. The default repository implementation builds a new map each time
that method is called, so the new version's properties were rebuilt once
per property of the old version. The ids that had already been seen were
also tracked in an ArrayList, turning each membership check into a linear
scan.
Read the properties of each repository once and use the old properties
map itself to detect the properties that have been added.
Computing the changelog between Spring Boot 3.4.0 and 3.5.0 (2,498 and
2,555 properties) drops from 203ms to 0.5ms and the generator's peak
memory from 302MB to 91MB. The generated asciidoc is byte for byte
identical.
See gh-51655
Signed-off-by: Junggi Kim <kimjg2477@gmail.com>
Baggage is already propagated over gRPC by the auto-configured
Micrometer observation interceptors: on the server side the
ObservationGrpcServerInterceptor hands the incoming metadata to the
tracing observation handlers, which extract the W3C baggage header as
well as the individual metadata keys listed in
management.tracing.baggage.remote-fields, and on the client side the
ObservationGrpcClientInterceptor writes them to the metadata of
outgoing calls. This was not documented, and it is easy to miss that
it requires micrometer-core on the classpath.
This commit adds an Observability section to the gRPC server
documentation, extends the gRPC client Observability section, and
mentions gRPC in the baggage section of the tracing documentation.
See gh-51597
Signed-off-by: Oleksandr Shevchenko <oleksandr.shevchenko@datarobot.com>
Packager#isCycloneDxBom only recognized CycloneDX SBOMs beneath
META-INF/sbom/. In a war, the CycloneDX Maven plugin's output is
packaged beneath WEB-INF/classes/META-INF/sbom/, so repackaging did
not add the SBOM manifest attributes.
Also check beneath Layout#getClassesLocation(), which findMainMethod
already uses to locate application classes. Continue to support the
root location used by jars.
Signed-off-by: COBI-98 <tkdgus968@naver.com>
See gh-51551
Phillip Webb
Andy Wilkinson
Tran Ngoc Nhan
Hyun Lee
Hyunwoo Jung
Ian Kettle
Stéphane Nicoll
ohchanKyu
Junggi Kim
Oleksandr Shevchenko
COBI-98