Added spring.cloud.function.definition property which is used by FunctionRegistry as a supplement instruction to resolve nameless lookups.
It is used by web module to map single or multiple (composed) functions to the root path (/)
Resolves#247
- 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
This is useful for example if the user is taking care of the
functional bean registration in some other way, and still wants to
use spring.functional.enabled=false to control that.
Reoved FunctionScan annotation since it provides no additional value to the end user
Preserved auto component scanning for Functions in package
Updated filter to additionally scan for Supplier and Consumer
Resolves#232
Resolves#233
Happens when HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTES is null
Can be seen when using spring-boot-starter-actuator with a scanned function
The path is null because the request wrapped by the WebMvcMetricsFilter is unmodifiable,
so setting the attribute in AbstractHandlerMethodMapping#handleMatch has no effect
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
