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.
Polished POM files to remove redundant entries that were causing warnings in the IDE. Some notable changes are:
- Removed spring-boot.version from sample project as they inherit it from the parent
- Removed versioning for maven-jar-plugin (was 3.0) from multiple project so it relies on the managed version
- Removed java.version from all spring-cloud-function-* modules as they inherit the one from parent.
Addressed PR comments
- removed references to maven-jar-plugin
Beans that are not created from a @Bean factory method do not have
the same kind of metadata. This change uses relection to extract
the target type from the bean definition if all else fails.
We don't need to cover all the possible uses of Flux (only
Flux<String> really), so this isn't comprehensive coverage of
all the features in Spring WebFlux, but it's good enough for
functions to run with Spring Boot 1.5.
Should be easy enoug hto add back later, but it was causing issues
with type conversion where we are npot yet sophisticated enough
to chain functions together and keep track of the types being
passed between them.
Make it deployable via its maven coordinates in
spring-cloud-function-deployer (it is deployed by default on start
up right now, but that's just a demo)
