From 649e0f9b7a1479c37dac8ec08444526d3ab0d772 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Mon, 29 Oct 2018 09:06:00 +0000 Subject: [PATCH] Sync docs from master to gh-pages --- ...ulti__building_and_running_a_function.html | 19 ++++++++++------- single/spring-cloud-function.html | 19 ++++++++++------- spring-cloud-function.xml | 21 +++++++++++-------- 3 files changed, 34 insertions(+), 25 deletions(-) diff --git a/multi/multi__building_and_running_a_function.html b/multi/multi__building_and_running_a_function.html index 62faa3405..9afad9ea3 100644 --- a/multi/multi__building_and_running_a_function.html +++ b/multi/multi__building_and_running_a_function.html @@ -6,14 +6,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.

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 be grouped together in a single application, or deployed +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.

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 functions can be deployed multiple times in different "personalities", exposing different functions over different physical transports.

\ No newline at end of file diff --git a/single/spring-cloud-function.html b/single/spring-cloud-function.html index bc3f893b1..9ac6a5305 100644 --- a/single/spring-cloud-function.html +++ b/single/spring-cloud-function.html @@ -36,14 +36,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.

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 be grouped together in a single application, or deployed +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.

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 functions can be deployed multiple times in different "personalities", exposing different functions over different physical transports.

4. Function Catalog and Flexible Function Signatures

One of the main features of Spring Cloud Function is to adapt and support a range of type signatures for user-defined functions, diff --git a/spring-cloud-function.xml b/spring-cloud-function.xml index 10bff787c..014db29fe 100644 --- a/spring-cloud-function.xml +++ b/spring-cloud-function.xml @@ -103,15 +103,18 @@ 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. -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). +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. +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 functions can be deployed multiple times in different "personalities",