This commit establishes the concept of binder identity (binder instance identity) to be used in cases where unique-to-the-binder-instance naming is required.
For example such naming is required to fix GH-2507 where error channel names could colide if two binders use the same destination name.
Resolves#2512Resolves#2507
Previously, when running in AOT mode the binder child context
was created w/ the same beans as when in JVM mode. The whole
point of the former is to static initialize an empty fresh context
using the AOT generated initializer.
Adapts to the following changes in upstreams libs:
- Spring Kafka removed ListenableFuture
- Spring AOT changed generator API
Fixes#2473#2465
Checkstyle fixes
This commit also includes partial work to ensure framework works in full native/AOT mode.
Also, PollableBean remains and will simply not work in AOT mode until https://github.com/spring-projects/spring-framework/issues/28748 is resolved. That said, i will be deprecating t and it will be removed in the next release given that we already have configurable alternative
Resolves#2456
An internal helper method used by StreamBridge for resolving the
binder target type to attach the target binder protocol, does not
take into account the binder name when resolving the binder configuration.
Fixing this issue.
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2379
Make binding names available through Consumer/Producer properties.
Currently, the binders use a ThreadLocal to store the binding name for internal use.
These changes introduce the binding name as a property for both producer/consumer bindings.
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2380
Related to https://stackoverflow.com/questions/72023445/spring-cloud-stream-mutually-exclusive-property-issue
The `PollerConfigEnvironmentPostProcessor` has a flaw not checking user-provided properties
and does not check for mutually exclusive before setting default
* Fix `PollerConfigEnvironmentPostProcessor` to check for other mutual poller
properties before setting default for `fixed-delay`
* Same for `max-messages-per-poll`
* Verify that fix is working in the `PollableSourceTests` where poller
options make sense in the Spring Cloud Stream scenario
* Fix `PollerConfigEnvironmentPostProcessor` for redundant check
* Add more tests into `PollableSourceTests` to verify different
poller properties and their exclusive mutuality
