- The `spring-cloud-stream-tuple` is now split into `spring-tuple`, `spring-integration-tuple` along with `spring-batch-tuple`
- Update dependencies to use the new ones
This resolves#326
Resolves#317
Remove the `durable` binder configuration property
Make subscriber groups durable by default
Introduce `requiredGroups` property
Kafka groups (non-anonymous) now start by default at EARLIEST, which is more appropriate for new stream consumers
Addressing PR comments
Resolves#330
- removes `unbind` from the binder and moves it to the `Binding` instance itself;
- `Binding` is now an interface with a default implementation provided by SCS
- Removed all methods from Binder except for unbind()
- Removed old and unused code
- Removed circular reference between default Binder and Binding implementations
- Removed Binder type
Fixesspring-cloud/spring-cloud-stream#314
Give more time to redis on travis
Make multipliers more versatile, apply to kafka
Extract receive() method. Default is now 1s
bump multiplier for kafka on travis
* removed pub/sub methods from binder
* consumer group is now a parameter of the remaining bindConsumer method
* remove DynamicProducer from Binder
* Move logic to create the dynamic channel to the channel resolver.
* Return bindings from bind methods and use them for unbinding
* Suffix for dlq
Move All Rabbit Binder CleanUp to Test Bindera
More RabbitMQ Binder Test Cleanup
Clean up declarations for remaining tests.
removed BinderUtils
use Redis ZSET for consumer groups
copyright dates
AutoBindDLQ: Single DLQ Per Group When Partitioned
Configure a single DLQ for each group for all partitions.
Add DLX Exchange binding for each original queue routing key, including the partition.
Fix DLQ Binding (Producer Side)
Option was not allowed and the routing key was wrong.
Add test to verify producers can be bound before consumers.
`autoBindDLQ` must be set (or reset) on both sides for success.
- Per-binding properties defined in `BindingProperties` need to hold the binder specific configurations needed when binding producer/consumers.
Previously, these were added in `ChannelBindingServiceProperties` as producer/consumer properties. Since these configuration properties are for
per-binding based on the input/output (consumer/producer) channel being bound it is better to move these properties into `BindingProperties`.
- Add some of the supported producer/consumer properties into BindingProperties
- This fixes#256
Rename CommonBinderProperties -> BinderPropertyKeys
Rename class AbstractBinderPropertiesAccessor.java -> AbstractBindingPropertiesAccessor.java
- Moved contents of `spring-cloud-stream-binder-spi` into `spring-cloud-stream`
- Removed `spring-cloud-stream-binder-local` and used local binder implementation for tests exclusively
- instead of publishing to the default exchange, producers now publish to a topic exchange, to which the main queue is bound
- taps on a stream simply bind a queue to the same exchange with a name including the group for the tapping stream and a
routing key pattern `#`
- this means that multiple instances of the same tap stream will compete but multiple tap streams will get a copy
- for partitioned data, a single topic exchange is used, which each partition queue bound with its name as the routing key
- this means taps on partitioned data see the consolidated messages
Remove unused binder utilities.
Use TopicExchange Always
Use a TopicExchange when binding a pubSub producer for consistency.
Remove Deprecated Binder Method
Add group to BindingProperties
- also fix artifact name in test support pom
- also fix some kafka tests (does not imply that kafka taps work - yet)
Fixes GH-166 (https://github.com/spring-cloud/spring-cloud-stream/issues/166)
Since `onInit()` in the `MessageChannelBinderSupport` was called before the `evaluationContext` population,
the `RedisMessageChannelBinder#errorAdapter` caused `NPE` for its `evaluationContext`.
* Change the initialization order
* Use `ExpressionUtils` to populate `evaluationContext` - creates `StandardEvaluationContext` if there is no one in the `applicationContext`
* Add more initializations for the `RedisMessageChannelBinder#errorAdapter`
* Remove explicit `evaluationContext` population from the `AbstractTestBinder` to rely on the fix for this ticket
* Some other simple polishing
Address PR comments
In order to join the Spring Cloud release train we have to align the
dependencies and (more importantly) the dependency management strategy.
The strategy is to not put version ids in <dependencies> (only
in <dependencyManagement>) where possible. And more importantly
we cannot use the releae train itself (creates a cycle).
This change achieves most of that (and mkae it possible for client
apps to use spring-cloud-starter-parent:Brixton.BUILD-SNAPSHOT)
Add spring-integration bom
