* 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
Resolve#229
* Optimizes connection factory creation for binders that can use Boot's autoconfiguration
* Make binder contexts a child of main context when creating a Binder with default configuration settings
* Inherit environment from main context when the Binder context is not a child, and make that optional
* Default environment inheritance to true
* Tests
- Addresses #138,#172,#173 with support for multiple binders in an application
- Binders can be of multiple types (e.g. Rabbit or Kafka), as well as multiple binders of the same type connecting to different system (e.g. multiple Rabbit binders connecting to different Rabbit clusters)
- Binders are now created in a separate context, allowing for multiple configurations
- Adds the `spring.cloud.spring.binders` namespace that allows for creating configuration properties for multiple binders
- Add support for default binder, modify Kafka tests to use multiple brokers when running embedded
- 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
- Re-add `@ConditionalOnMissingBean` to connection factory beans in cloud configurations
- This is needed at least for CF case where auto-reconfiguration sets up connection factory beans
- Remove lattice and cf connector dependencies from core S-C-S and binder
- The idea is to have these dependencies defined in s-c-s-modules so that they
are specified in one place and make the module run on local/cloud environment in a
self contained manner
- Keep the `spring-cloud-core` dependency to binder so that the Cloud configuration
is used to get the appropriate services for the redis/rabbit binder
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
