- does not rely on any of the existing wrappers and instead relies on internal wrapper which performs in-flight/just-in-time wrapping and unwrapping from reactive to imperative types
- performs transparent type conversion relying on MessageConverters and ConversionService
- supports multiple inputs/outputs
- Added JDK 11 hook in FunctionCreatorConfiguration for javax.annotation to be loaded from current CL
- Ensured the file: protocol resources end with the forward slash. See UrlClassPath.getLoader of JDK 11 for more details as to why
- Re-enabled conditional tests by removing Java 8 assumptions
- Part of the issue was also, the invoker plugin which was only generating ‘it/..’ directory every other time due to exists condition, thus resulting in some test failures every other time (missing directory)
Resolves#251
If there is a unique function it should be unambiguous. This change
also supports multiple functions, but the naming is unhelpful then
("function[0,1,2,]").
User can now provide a Function or an ApplicationInitializer. Also
the initializer can create a FunctionRegistration with the handler
name instead of a bean with the handler name. Better control of
input and output types that way.
Fixes gh-231
Updated both the interface as well as InMemoryFunctionCatalog BeanFactoryFunctionCatalog and SingleEntryFunctionRegistry implementations
Added tests
Resolves#199
Some tests still ignored.
Also adds draft functional bean registration support. The AWS sample
is using that now (it starts up 4x faster in AWS). To activate the
functional beans user has to supply a main class of type
ApplicationContextInitializer.
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.
