- 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
- For the message channels being created, set the corresponding `dataType` and `message-converters` based on the `contentType` value set per-binding
- This is applicable for both direct-binding and the channels that connect to the binder
- Add a way to enable `RxJava` module
- Add `EnableRxJavaModule` annotation that inherits `EnableModule` for `Processor` type.
- It also registers the custom `MessageHandler` that sets up RxJava `Observable/Subscriber` to process the incoming message reactively.
- Introduce `RxJavaProcessor` that is expected to be implemented by the module author with the input/output being `Observable`. This processor is autowired into the message handler registered above.
- Add moving average sample
Add project `spring-cloud-stream-rxjava`
- This project extends `spring-cloud-stream` so that any RxJava processing module would have this as a dependency
* renamed @ModuleChannels to @Bindings
* moved Source, Sink, and Processor to the `org.springframework.cloud.stream.messaging` package
* updated documentation
and refactor channel proxy behaviour
- Remove DirectChannelProxyFactory;
- Proxies create channels as necessary, including support for PollableChannels;
- Channel beans are using the bean factory methods for the proxies;
- Coordinate bind/unbind across a context through the internal Bindable interface;
- Add support for embedding modules as independent child contexts of the main module, wrapped in a Bindable interface;
- Add support for channel name namespacing;
- Use a shared channel registry (consulted by the proxies) to create direct bindings;
Restrict the use of SharedChannelRegistry to aggregation
Fixed copyrights
Polishing based on comments from the previous branch
Tweaks
- namespacing takes into account module index, so multiple modules with the same class can partiticipate
- fix how properties are passes to parent/child
- Split ChannelBindingLifecycle from ChannelBindingAdapter and register it with each child;
Javadoc updates
Pass only prefixed properties
Actually use the filtering method
Lifecycle simplifications
- Removing BindableChannelWrapper and UnbindOnCloseApplicationListener and relying on ChannelBindingListener solely;
- Some code cleanup
Further simplifications
More cleanup
Remove BindableUtils, rename ChannelBindingAdapter
Minor improvements
Addressing some comments, renaming, etc
More polishing
- Since the ChannelBindingAdapter is `SmartLifecycle` bean and it starts before
the message producing time source adapter we can remove explicit `autoStartup=false` for TimeSource sample
(And with existing Spring Cloud projects.) Uses a maven plugin to
build the image. It can be pushed manually, or else using
-Ddocker.image.prefix=<path_to_repo>. Removes some of the hard-coded
host names and stuff that came with the old version.
Standard channel interface types of Sink, Source, Processor
are provided, but user can create others with @Input and
@Output MessageChannel methods.
To get the declared channels in an app you can use the
@ModuleChannels qualifier to inject the interface, e.g.
@ModuleChannels(Cafe.class) injects the channels defined
in the Cafe.
