# spring-cloud-stream-samples

**Repository Path**: zhangchengji/spring-cloud-stream-samples

## Basic Information

- **Project Name**: spring-cloud-stream-samples
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Apache-2.0
- **Default Branch**: 1.0
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2021-05-25
- **Last Updated**: 2021-05-25

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

== Samples

There are several samples, all running on the RabbitMQ transport (so you need RabbitMQ running locally to test them).

To build the samples do:

```
   ./mvnw clean build
```

NOTE: The main set of samples are "vanilla" in the sense that they are not deployable as XD modules by the current generation (1.x) of XD. You can still interact with an XD system using the appropriate naming convention for input and output channel names (`<stream>.<index>` format).

* `source` is a Java config version of the classic "timer" module from Spring XD. It has a "fixedDelay" option (in milliseconds) for the period between emitting messages.

* `sink` is a Java config version of the classic "log" module from Spring XD. It has no options (but some could easily be added), and just logs incoming messages at INFO level.

* `transform` is a simple pass through logging transformer (just logs the incoming message and passes it on).

* `double` is a combination of 2 modules defined locally (a source and a sink, so the whole app is self contained).

* `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.