- Enhanced HTTP endpoint mapping support for 'functional form' context configuration ensuring it can register multiple endpoint to maintain the same behaviour as with regular application context
- Additional consolidation around Function Catalog
- Added identical test for functional and non-functional form endpoint configuration.
Resolves#293
- 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
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.
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.
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.
User can POST to web endpoint in SSE style, i.e:
HTTP/1.1
Content-Type: text/event-stream
data:foo
data:bar
Will be converted to a Flux with values foo and bar
