-
Notifications
You must be signed in to change notification settings - Fork 310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error on Testing #481
Comments
Is there any reason you're not using |
Closing due to no response from OP. |
prash-mi
pushed a commit
that referenced
this issue
Jun 20, 2023
This PR adds three additional types of parameter binding: 1) primitive arrays. These were straightforward to match, knowing the incoming object type, and are implemented with existing `ClientLibraryTypeBinderImpl`. 2) wrapper type arrays or primitive arrays where type conversion is needed. These need to be converted from an array to a list to use the list-accepting overloads of client library value binder. I've implemented a helper class `ArrayToIterableBinder` to avoid duplicating list creation boilerplate. 3) Iterable/Collection. This was harder, since the client library has typed binding methods, but parameterized types aren't real ("reified") in Java. This is, however, possible with R2DBC SPI 0.9 `Parameter.in()` binding. It's implemented with one binder for all `Iterable` needs -- `IterableBinder`, which uses some hardcoded type maps in `SpannerType`. I've updated `ClientLibraryTypeBinder` to accept `SpannerType` hints, but for now only the `IterableBinder` uses these values. We may have use for the additional type hinting in the future, though, so we might as well give the binders all useful information up front. (3) is not necessary to bind collections with Spring Data, because all collections get converted to arrays internally, so by the time the value gets to the driver, it's already an easily digestible array. `SpannerArrayColumns` and `SpannerR2dbcDialect` changes are needed to trigger this logic in Spring Data. I've simplified the front-end to send and retrieve a whole Book object, because adding another field with another button would be too complicated for users. Fixes #481.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I am using spring-cloud-gcp and pubsub as follows :
2.4.5
<spring-cloud.version>2020.0.2</spring-cloud.version>
<spring-cloud-gcp.version>2.0.0</spring-cloud-gcp.version>
Everything runs well until I run the tests.
On tests I always get an error on Sleuth, as follows :
No qualifying bean of type 'org.springframework.cloud.sleuth.instrument.web.servlet.TracingFilter' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}
Removing springboot gcp everything goes allright.
The text was updated successfully, but these errors were encountered: