- Add `MessageChannelConfigurer` that any class that configures the message channel would implement
- Have `message-converter` and `message-history-tracking` configurer implement this interface
- Autowire all available configurers and use them to configure the message channel
- For the message history tracking
- add `channel-binding` properties as part of message header along with `timestamp`
- Introduce CompositeMessageChannelConfigurer
Remove field injection of messageChannelConfigurer
Add tests for message track history configurer
Add content-type configurer test
Address review comments
- Add `toString` to BindingProperties
- Add test case to depict producer/consumer properties
Remove processor channels from tests
* tidy up pom to remove redundant section
* provide simple fall back for building non branch changes in travis
* Add -s .settings.xml to .mvn/maven.config
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
The DefaultBinderFactory makes use of SpringApplicationBuilder to
build a context containing a binder. It has access to the Environment
of the surrounding context, but doesn't use it, and doesn't use it
(before this change). Users will be surprised if (for instance) they
change the default rabbitmq hostname and the change doesn't propagate
to the binder.
- 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
Resolvesspring-cloud/spring-cloud-stream#92
Also
* Remove publishing build configuration from .travis.yml
This are not needed as we use Bamboo for release managment
* javadoc and surefire plugins added to pom.xml
- 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
- ChannelFactory to create message channels and configure message converters
Autowire ChannelFactory
Create message channel on demand
ChannelFactory implementation to use SharedChannelRegistry
Create ChannelFactory interface
If the broker was down, the binding failed. Defer the queue/exchange/binding declarations
until the broker is available (already supported by `RabbitAdmin`.
Solves spring-cloud/spring-cloud-stream#203
Fix PubSub, Test
- Too many binder prefixes on pub sub queue name.
- Mismatched queue args in test case.
- 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
