The PulsarTemplate recently replaced its list of ProducerInterceptors
with a list of ProducerBuilderCustomizers that customize the builder by
adding each interceptor to the builder. The PulsarAutoConfigurationTests
previosuly relied on the previous field. This commit adjusts the tests
to instead use the Customizers testing utility to verify the
interceptors.
(cherry picked from commit 9c054a021f)
See gh-39946
The PulsarTemplate recently replaced its list of ProducerInterceptors
with a list of ProducerBuilderCustomizers that customize the builder by
adding each interceptor to the builder. The PulsarAutoConfigurationTests
previosuly relied on the previous field. This commit adjusts the tests
to instead use the Customizers testing utility to verify the
interceptors.
See gh-39912
Prior to this commit, Spring Boot auto-configurations for GraphQL web
endpoint were implementing their own `RequestPredicate` instances for
HTTP endpoints. Those were composing predicates with the provided DSL.
While this is functionnally right, Spring for GraphQL now provides
predicates in order to:
* host the implementation in spring-graphql directly
* provide optimized predicates for faster matching and lower overhead
This commit switches the auto-configurations to using these new
predicates.
Closes gh-39652
This commit adapts the error controller tests that need the request
to fail with a bind issue, and simulate the behavior of
ModelAttributeMethodProcessor.
As of Spring Framework 6.0.x, this processor no longer throws a
BindingException, but rather a MethodArgumentNotValidException and
the handing of BindException itself is deprecated.
This makes sure that those tests can smoothly be executed against
Spring Framework 6.2.x as throwing a BindingException now results
into an unresolved exception, and an internal server error rather than
the expected bad request.
See gh-39767
This commit moves the resolution check for ConnectionDetailsFactory
to a dedicated method to make it more clear that it is meant to verify
that the implementation is resolved and can be loaded from the
classpath.
The previous algorithm relied on a behavior of ResolvableType that only
resolves the first level generics. Further improvements in Spring
Framework 6.2 make this check invalid as some implementations use a
Container that can hold a nested generic.
See gh-39737
