This makes dynamic function registration (after context starts) much
easier. Also frees us from having to employ BeanFactoryPostProcessor
and other tricks to get the functions registered on startup.
- attempted to make code more functional (eat our own dog food) and concise
- addressed PR comment
- additional cleanup/polishing of FunctionUtils and related classes
- Removed Function/Supplier/ConsumerProxy classes by extending type info on their super interface
- Renamed FunctionUtils to FunctionFactoryUtils
- Added javadoc to FunctionFactoryUtils to explain its design considerations as well as what it can and can not doi
Fixes gh-90
The compiled functions implement that interface which means you can inspect
the signature of the method that created them and discover its
generic types.
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
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
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)
* extracted FunctionGateway interface
* renamed current implementation to LocalFunctionGateway
* moved `compose` methods from FunctionGateway to FunctionRegistry
