* Migrate Kafka Streams branching sample
* Cleanup some Kafka samples
* copyright header added to several files
* Spring Boot Maven plugin put into parent samples pom.xml
* Removed unused dependency and fixed title in README.adoc
When DLQ is enabled on a consumer binding, the internal producer properties
used by the DLQ mechanism to send to the topic is not populated with the
correct binding name. In the previous version, it was working fine since
we were relying on a ThreadLocal. This is revamped recently to properly
introduce a binding name as a top level property in ProducerProperties.
However, this was not set on the internal producer properties used by the
DLQ. This PR addresses this issue.
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2417Resolves#2418
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/2379Resolves#2401
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 confluent-schema-registry-integration sample poms consistent
* Update <description> w/ "Confluent" prefix
* Put spring-cloud-dependencies back to 2022.0.0-SNAPSHOT (I got confused w 2021 for a minute)
* Pull deps up to base pom.xml
* Refactor SerdeResolverUtils logic
* Add more tests in SerdeResolverUtilsTests
* Fixed some random test warnings
Fixes#2370
Code review feedback: remove FQ ref to inner method
Fix checkstyles
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
Fixes https://github.com/spring-cloud/spring-cloud-stream/issues/2359
The KCL mode does not apply at the moment `AT_TIMESTAMP` and `TRIM_HORIZON` initial offsets
Resolves#2365
* Change the `KinesisMessageChannelBinder` binder logic to create an explicit
`KinesisClientLibConfiguration` based on the provided properties including
custom stream iterator type
* Adjust `KinesisTestBinder` to be able to create a KCL/KPL based bindings
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
