It tends to pop back into function apps where it is not needed
otherwise. Users that want to use the library need to import
the FunctionConfiguration directly using the
@EnableFunctionDeployer convenience annotation..
Instead of an app, it is now a library with some utilities
(principally ApplicationBootstrap) for launching a Spring Boot
application, extracting a function, and registering it in the
FunctionRegistry.
Makes it possible to support other "function" types in the future.
The user is always taking a risk with the lookup that the object
returned has the generic type desired (but that hasn't changed
with this commit). FunctionCatalog is a lot simpler as a result
and also a lot more flexible.
With this change there are now 2 choices for web endpoints. The
stream servlet binder is useful for multi-binder use cases
(e.g. HTTP -> message broker).
It didn't really make any sense to have custom conditions that
depend on the presence or absence of beans of type Function,
Supplier, Consumer because the actual endpoints are derived
from the FunctionCatalog (which might not be based on
bean definitions). This approach is far simpler, and
reduces the amount of custom code in the stream binder.
The spring.cloud.function.stream.supplier.enabled flag
is awkward, so we should try and find a way to avoid that.
There's also no reason it should need to be set in the
deployer tests.
Functions are namespaced under the "app name", e.g.
/sample/uppercase is the "uppercase" function in the "sample" app.
Also added a README to get started quickly.
The controller doesn't need to know the mappings, and it helps
to keep them closer to the actual AppDeployer, so in a future
change we can use the app names to look up functions.
The FunctionInspector needs to be able to distinguish between a
function of Flux<Foo> and a function of Flux<Message<Foo>>. Then
it can do the conversion a level below.
Only supports Message->Message or POJO->POJO (no mixtures), so there
is only one new method in FunctionInspector.
No support in the web endpoints yet. But it's probably not so hard
to add.
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
