diff --git a/README.adoc b/README.adoc index 2b4291275..4ca103e45 100644 --- a/README.adoc +++ b/README.adoc @@ -84,6 +84,10 @@ NOTE: The main set of samples are "vanilla" in the sense that they are not deplo * `extended` is a multi-module mashup of `source | transform | transform | sink`, where the modules are defined in the other samples and referred to in this app just as dependencies. +* `multibinder` is a sample application that shows how an application could use multiple binders. In this case, the processor's input/output channels connect to different brokers using their own binder configurations. + +* `multibinder-differentsystems` shows how an application could use same binder implementation but different configurations for its channels. In this case, a processor's input/output channels connect to same binder implementation but with two separate broker configurations. + If you run the source and the sink and point them at the same redis instance (e.g. do nothing to get the one on localhost, or the one they are both bound to as a service on Cloud Foundry) then they will form a "stream" and start talking to each other. All the samples have friendly JMX and Actuator endpoints for inspecting what is going on in the system. == Module or App diff --git a/spring-cloud-stream-docs/src/main/asciidoc/spring-cloud-stream-samples.adoc b/spring-cloud-stream-docs/src/main/asciidoc/spring-cloud-stream-samples.adoc index 443968137..9676e204a 100644 --- a/spring-cloud-stream-docs/src/main/asciidoc/spring-cloud-stream-samples.adoc +++ b/spring-cloud-stream-docs/src/main/asciidoc/spring-cloud-stream-samples.adoc @@ -14,5 +14,10 @@ There are several samples, all running on the redis transport (so you need redis * `extended` is a multi-module mashup of `source | transform | transform | sink`, where the modules are defined in the other samples and referred to in this app just as dependencies. +* `multibinder` is a sample application that shows how an application could use multiple binders. In this case, the processor's input/output channels connect to different brokers using their own binder configurations. + +* `multibinder-differentsystems` shows how an application could use same binder implementation but different configurations for its channels. In this case, a processor's input/output channels connect to same binder implementation but with two separate broker configurations. + + If you run the source and the sink and point them at the same redis instance (e.g. do nothing to get the one on localhost, or the one they are both bound to as a service on Cloud Foundry) then they will form a "stream" and start talking to each other. All the samples have friendly JMX and Actuator endpoints for inspecting what is going on in the system.