The values in the `spring.pulsar.client.authentication.param`
config props map are not currently JSON encoded. For simple
values this is fine. However, some custom auth modules may
require more complex parameter values that may contain special
characters that results in invalid JSON. This commmit encodes
the parameter values using a very simple hand-rolled escape
function.
See gh-40493
This reverts commit 06f5ab162f6b049f42f15c04d3a9a8810c0c6d63. The
dependency has been removed in Data Couchbase, making the exclude
unnecessary.
See gh-40200
This reverts commit 06f5ab162f6b049f42f15c04d3a9a8810c0c6d63. The
dependency has been removed in Data Couchbase, making the exclude
unnecessary.
See gh-40200
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 9c054a021fc34728a68a835a5c2e421f3e11df9f)
See gh-39946
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
