Ensured we have Custom Runtime examples for functional and '@Bean' style
Improve AWSLambdaUtils to ensure it works without APIGatewayProxyRequestEvent on classpath
This commit provides initial set of improvements to executing functions in AWS Custom Runtime
- Consistent invocation model for functional as well as @Bean configuration models via new CustomRuntimeEventLoop as well as AWSLambdaUtils
- Clean up classpath to decrease the size of the JAR/ZIP file
- Configuration simplification which no longer requires enabling of function exporter
It also allows user to define functions that rely on AWS types such as APIGatewayProxyRequestEvent
The existing invocation model remains in tact for the time being. Both invocation models are mutually exclusing in theit setup to avoid potential conflict.
Resolves#538Resolves#630
Add test in AWS to showcase type conversion
Fix AWS FunctionInvoker to delegate to effectively delegate type conversion to the native mechanism of spring-cloud-function
Resolves#562
This assumes that
- 'body' will be extracted for cases such as POJO or String input
- Map input will simply represent the incoming request
- APIGatewayProxyRequestEvent input represents native representation of API Gateway request
Similar fixes went for Kinesis side of things
Added additional tests for both Kinesis and ApiGateway
- Add 'contentType' property to ExporterProperties to assist SupplierExporter with delegating it to function catalog
- Add additional logging and testing
- Change JsonMapper to abstract class providing special handling of conversion of Json Sting to byte[]
Added support for function filtering in the event there are more then one function in catalog. This is primarily to ensure that
we have a mechanism to specify which functions to export as web enpoints (instead of all)
Resolves#460
- Added generic FunctionInvoker capable of handling the request generically without requiring user to implemen specific AWS request handler
Resolves#434
- 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
* Add support for handling APIGatewayProxyRequestEvent objects with
empty body (should apply to all GET and DELETE requests, which
comply with recommandation of RFC-7231)
* Add support ReSTful APIs: path and query string parameters as well
as the HTTP method are now extracted from the
APIGatewayProxyRequestEvent object and forwarded to the function
as message headers
* Extend unit tests accordingly
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
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.
SpringApplication looks like the class with the same name in Spring
Boot (and is a subclass of it), but it checks to see if the user
is asking for functional bean registrations and only used those if
it can.
