- 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
- Fixed issue which was causing one of the new tests to fail *only* when running as ‘mvn install’
- Modified HttpSupplier to return a delayed Mono for non2xx responses. Add javadoc
- Added conditional retry ability to the SupplierExporter to handle both ConnectionException for cases when connection may not be available or disappears during subscription.
- Polished error handling and lifecycle logic in SupplierExporter
- Added test demonstrating both retries as well as lifecycle control
Resolves#268
Kind of like the SupplierExporter but to create the Supplier itself.
With this in place you can define the templateUrl (destination) and
the originaUrl (source) and use the app as a pipeline for events
from/to HTTP.
Provide functional bean support for HTTP export
Add autoconfig to AWS adapter for custom runtime
Fix HttpSupplier to always supply Message if headers are included
Fix registration of origin supplier in functional beans
Add docs on new AWS features
Add custom runtime sample
- Added wrapper for an already reactive consumer to ensure that consumers can be consistently represented as Function<Flux, Mono>
- Fixed the big that deal with inconsistent result in web environments due to inconsistent representation of the Consumers
- Polished tests
Resolves#243Resolves#257
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
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.
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
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
Added support for function parameter type Collection
Updated both Jackson and Gson mappers
Defined a new toObject() operation on JsonMapper and deprecated the old
Resolves#210
We want the default application type to be REACTIVE if webflux is
present (formerly it was NONE). In AWS and Azure we also want
the webflux beans to be switched off in a "lite" application
context (formerly they were unconditional).
