Bumping versions

This commit is contained in:
buildmaster
2018-11-16 15:20:37 +00:00
parent 417a6a75c1
commit b23a647aa4
2 changed files with 11 additions and 12 deletions

View File

@@ -100,18 +100,17 @@ or a Stream processor, for instance with RabbitMQ, Apache Kafka or
JMS.
The `@Beans` can be `Function`, `Consumer` or `Supplier` (all from
`java.util`), and their parametric types can be String or POJO. A
`Function` is exposed as a Spring Cloud Stream `Processor` if
`spring-cloud-function-stream` is on the classpath.
A `Consumer` is also exposed as a Stream
`Sink` and a `Supplier` translates to a Stream `Source`.
HTTP endpoints are exposed if the Stream binder is `spring-cloud-stream-binder-servlet`.
`java.util`), and their parametric types can be String or POJO.
Functions can be of `Flux<String>` or `Flux<Pojo>` and Spring Cloud
Function takes care of converting the data to and from the desired
types, as long as it comes in as plain text or (in the case of the
POJO) JSON. TBD: support for `Flux<Message<Pojo>>` and maybe plain
`Pojo` types (Fluxes implied and implemented by the framework).
Functions can also be of `Flux<String>` or `Flux<Pojo>` and Spring
Cloud Function takes care of converting the data to and from the
desired types, as long as it comes in as plain text or (in the case of
the POJO) JSON. There is also support for `Message<Pojo>` where the
message headers are copied from the incoming event, depending on the
adapter. The web adapter also supports conversion from form-encoded
data to a `Map`, and if you are using the function with Spring Cloud
Stream then all the conversion and coercion features for message
payloads will be applicable as well.
Functions can be grouped together in a single application, or deployed
one-per-jar. It's up to the developer to choose. An app with multiple

View File

@@ -64,7 +64,7 @@ The input type for the function in the Azure sample is a Foo with a single prope
}
----
NOTE: The Azure sample app is written in the "non-functional" style (using `@Bean`). The functional style (with just `Function` or `ApplicationContextInitializer`) is is much faster on startup in Azure than the traditional `@Bean` style, so if you don't need `@Beans` (or `@EnableAutoConfiguration`) it's a good choice. Warm starts are not affected.
NOTE: The Azure sample app is written in the "non-functional" style (using `@Bean`). The functional style (with just `Function` or `ApplicationContextInitializer`) is much faster on startup in Azure than the traditional `@Bean` style, so if you don't need `@Beans` (or `@EnableAutoConfiguration`) it's a good choice. Warm starts are not affected.
== Sample Function