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:
@@ -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
Reference in New Issue
Block a user