Spring Kafka 4.2 adds ContainerProperties#setAwaitAsyncResultsOnStop:
when the container stops, in-flight asynchronous listener results
(CompletableFuture, Mono, Kotlin suspend functions) are awaited within
the shutdown timeout and cancelled afterwards, so that listener work
does not outlive the container.
This commit adds spring.kafka.listener.await-async-results-on-stop so
that this can be enabled with configuration rather than a
ContainerCustomizer.
See gh-51774
Signed-off-by: Nikita Kibitkin <nikita.n.kibitkin@gmail.com>
This commit adds a spring.kafka.listener.admin and
spring.kafka.template.admin namespace with similar configuration
properties than spring.kafka.admin, used to create the KafkaAdmin bean.
When a property is configured in those two namespaces, a dedicated
KafkaAdmin is created and associated with the relevant component.
Closes gh-38830
This commit introduces a centralized way of building Kafka config
properties, and deprecate the equivalent in KafkaProperties. This
also removes the customization done in auto-configuration so that
KafkaConfigBuilder is the sole source mapping.
KafkaConfigBuilder also takes care of applying ConnectionDetails if
necessary.
Closes gh-51769
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>
This commit adds new "spring.graphql.http.methods" and
"spring.graphql.http.sse.methods" configuration properties that let you
configure the allowed HTTP methods for the given transports.
Closes gh-51732
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
With OpenTelemetry, fields listed in management.tracing.baggage.tag-fields
only became span tags when the application itself touched the baggage
through the Tracer API. Baggage that arrived with a request was
propagated correctly, but spans were not tagged with it (see
micrometer-metrics/tracing#933).
This commit registers Micrometer Tracing's BaggageTaggingSpanProcessor
whenever baggage is enabled and at least one tag field is configured, so
that spans are tagged with the baggage that is present in their parent
context. A custom BaggageTaggingSpanProcessor bean backs off the
auto-configured one. The tag-fields property is now also mentioned in
the baggage section of the tracing documentation.
See gh-51656
Signed-off-by: Oleksandr Shevchenko <oleksandr.shevchenko@datarobot.com>