Add initial support for functions wih multiple inputs/outputs as well as multiple functions

- Currently there is no multi-out support for Supplier and I am not really sure what the use case would be so holding off.
- The logic in FunctionConfiguration effectively split in bootstrapping simple functions (e.g., Function<String, String>) vs. multi-in/out (e.g., Function<Tuple2<Flux<String>, Flux<String>>, Flux<String>>). This is temporary given that multi-in/out is still considered WIP. Once it becomes stable we can merge the two two for consistency.
- Added multiple input/output support for TestBinder
- Updated documentation

Resolves #1746
Resolves #1745
Resolves #1314
This commit is contained in:
Oleg Zhurakousky
2019-09-16 11:51:21 +02:00
parent 1723a40786
commit c56b4d1ea9
10 changed files with 1169 additions and 1045 deletions

View File

@@ -85,16 +85,17 @@ Modify the `com.example.loggingconsumer.LoggingConsumerApplication` class to loo
[source, java]
----
@SpringBootApplication
@EnableBinding(Sink.class)
public class LoggingConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(LoggingConsumerApplication.class, args);
}
@StreamListener(Sink.INPUT)
public void handle(Person person) {
System.out.println("Received: " + person);
@Bean
public Consumer<Person> log() {
return person -> {
System.out.println("Received: " + person);
};
}
public static class Person {
@@ -114,10 +115,10 @@ public class LoggingConsumerApplication {
As you can see from the preceding listing:
* We have enabled `Sink` binding (input-no-output) by using `@EnableBinding(Sink.class)`.
Doing so signals to the framework to initiate binding to the messaging middleware, where it automatically creates the destination (that is, queue, topic, and others) that are bound to the `Sink.INPUT` channel.
* We have added a `handler` method to receive incoming messages of type `Person`.
Doing so lets you see one of the core features of the framework: It tries to automatically convert incoming message payloads to type `Person`.
* We are using functional programming model (see <<Spring Cloud Function support>>) to define a single message handler as `Consumer`.
* We are relying on framework conventions to bind such handler to the input destination binding exposed by the binder.
Doing so also lets you see one of the core features of the framework: It tries to automatically convert incoming message payloads to type `Person`.
You now have a fully functional Spring Cloud Stream application that does listens for messages.
From here, for simplicity, we assume you selected RabbitMQ in <<spring-cloud-stream-preface-creating-sample-application,step one>>.
@@ -152,32 +153,18 @@ You can also build and package your application into a boot jar (by using `./mvn
Now you have a working (albeit very basic) Spring Cloud Stream application.
== What's New in 2.2?
Spring Cloud Stream introduces a number of new features, enhancements, and changes in addition to the once already introduced in
https://docs.spring.io/spring-cloud-stream/docs/Elmhurst.SR2/reference/htmlsingle/#_what_s_new_in_2_0[version 2.0]
The following sections outline the most notable ones:
* <<spring-cloud-stream-preface-new-features>>
* <<spring-cloud-stream-preface-notable-enhancements>>
== What's New in 3.0?
TBD
[[spring-cloud-stream-preface-new-features]]
=== New Features and Components
TBD
[[spring-cloud-stream-preface-notable-enhancements]]
=== Notable Enhancements
TBD
[[spring-cloud-stream-preface-notable-deprecations]]
=== Notable Deprecations
As of version 2.2, the following items have been deprecated:
- The spring-cloud-stream-reactive module is deprecated in favor of native support
via <<spring_cloud_function, Spring Cloud Function>> programming model.
=== Notes on migrating from 1.x to 2.x?
- Due to the improvements in content-type negotiation, the `originalContentType` header is not used (ignored) since 2.x and only exists for maintaining compatibility with 1.x versions
- Introduction of `@StreamRetryTemplate` qualifier. While configuring custom instance of the `RetryTemplate` and to avoid conflicts you must qualify the instance of such `RetryTemplate` with this qualifier. See <<Retry Template, Retry Template>> for more details.
TBD

File diff suppressed because it is too large Load Diff