If there is only one function you shouldn't have to set any configuration
to get a stream app to run. This also implementation supports multiple
functions, trying to guess which one to use based on the type of
the incoming message payload. In principle that could be strategized
as a simple router function (e.g. to look for a header with a function
name).
If there are functions and consumers in the same app, they will
subscribe to the same input channel (and hence by default Spring
Integration will load balance between them). This could also probably
use some more features, to specify the desired behaviour.
If user *does* supply spring.cloud.function.stream.endpoint then it
is used and overrides all other possible routes.
The compiled functions implement that interface which means you can inspect
the signature of the method that created them and discover its
generic types.
Compiled functions always show up with no metadata, and you can only
guess what the types are from the bean definition. Probably we should
add more information to the bean definition if we have it when we
compile the function.
There is still a problem if user defines functions that are not of
Flux<String> (but that has always been the case).
Lambdas generally only deal with single values anyway, but for
consistency we should return similar results from a Lambda handler
as from an MVC handler in s-c-f-web.
If the request is a single value, we already know, so if we also
know that the function returned a single-valued type, then we can
render the single value, instead of an array with a single item.
See gh-36
These can be used to more reliably discover whether the user
has declared a function with flux types or "bare" POJOs. They
then pave the way to supporting single valued types in a special
way.
Also consolidate and simplify the logic in FunctionInspector
So that single Strings can be POSTed without JSON conversion.
There's still some work to do to support single POJOs in JSON, and
to reach parity with the WebFlux reactive type handlers, but it's
now closer to what we had before we moved the String conversion
out of the function layer.
There is one behaviour change (you have to POST an array to a function
endpoint if you are sending a body), and also a message converter that
needed to be removed so that arrays are not toStringed in the response
body.
- use ProxyWrapper around a FluxConsumer as well
making it consistent with the behaviour of Flux
functions
- Enable introspection for scanned beans
- Fix failing tests by passing JSON string as input messages
(marshalled form expected from the binder)
A bean of type FunctionRegistration registers the function with
user-specified name and other properties, rather than relying on the
bean name.
Alternatively, function catalog keys can be specified as a
@Qualifier, which will be used instead of the bean name if
no registration is found.
