- 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 ability to retrieve input type from FunctionRegistration (if available) in AbstractSpringFunctionAdapterInitializer
- Removed azure/AzureSpringFunctionInitializer and aws/SpringFunctionInitializer
- Added additional tests in AWS and Azure modules
- See 0189c578ef for additional info
- Moved common logic into a new AbstractSpringFunctionAdapterInitializer
- Modified Azure and AWS request handlers to extend from it
- Deprecated both AzureSpringFunctionInitializer and SpringFunctionInitializer(AWS)
Resolves#266
Without this change the type of a composed function in the
InMemoryFunctionCatalog is always null. The key is to register
the type at the same time as the function is registered.
Also some format and javadoc fixes (cosmetic)
Added support for Consumer and Supplier functions when executing within AWS Lambda.
It appears that this was previously supported but was removed in 083d5e for some reason.
Improve Consumer support for AWS API Gateway
Consumer type functions, by definition, do not return anything; i.e. they do not have a response. However when executing within a Lambda + API Gateway environment, the Lambda must still return a 200-level status response to signal the API Gateway that the function executed succesfully. I added the logic for this.
Improve Supplier support for AWS API Gateway
Supplier functions, by defnition, do not take input; in the case of API Gateway calls this type of execution passes a null body, which fails to deserialize and throws an exception. I added logic that skips the deserialization of the body in the case it is a Supplier.
Added logic in FunctionalSpringApplication to avoid registering the functional bean twice. This issue occured when executing in "hybrid" mode, and using the same bean as both the application context source and functional bean.
- 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
- 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
