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>
The deprecation entry for
management.prometheus.metrics.export.pushgateway.base-url was declared
as "management.promethus", so the deprecation was never reported.
Signed-off-by: ohchanKyu <okc0202@naver.com>
See gh-51627
This commit improves TestImage so that an explicit image can trigger
the creation of the container, with optional additional setup. This
removes the need of creating additional container types for images that
have multiple flavors, and to please the static method that can only
create a container based on a single match.
Closes gh-51082
Prior to this commit, CloudFoundryReactiveActuatorAutoConfiguration
registered a BeanPostProcessor replaced the WebFilterChainProxy bean
with one that handled CF security and delegated to the existing
chain.
Constructing a new WebFilterChainProxy resulted in the loss of any
firewall customization on the existing chain as Spring Security does
not provide an API to retreive the firewall from the existing chain
and apply it to the new chain.
This commit changes the approach and aligns it with its Servlet
counterpart. Instead of post-processing the filter chain proxy, a new
SecurityWebFilterChain that handles cloudfoundryapplication/**
is defined. This chain becomes part of the existing
WebFilterChainProxy, preserving any firewall customization.
Signed-off-by: aashikantkumar <aashikantkumar2@gmail.com>
See gh-51549
Previously, the CloudFoundryAuthorizationExceptions thrown for a
missing application ID or cloud controller URL were not routed
through the error handling that turned them into a SecurityResponse
with a 503 status code. As a result, they were processed by the
general exception handling which resulted in a 500 response.
This commit updates the reactive SecurityInterceptor so that the
exceptions are processed through
SecurityInterceptor::getErrorResponse. This aligns the behavior of
the Cloud Foundry security intergration in a reactive application
more closely with that of a Servlet application.
Fixes gh-51613
Brian Clozel
Stéphane Nicoll
ohchanKyu
Tran Ngoc Nhan
Andy Wilkinson
Oleksandr Shevchenko
htjworld
JaeHyunAn
aashikantkumar