Refactor and simplify AWSLambdaUtils to work with AWS serialization libraries
Add support for API v2 gateway event
Resolves#709Resolves#684Resolves#641
Introduce auto-fallback to routing function if more then one function is present and no definition is provided.
Add explicit routing sample
Add documentation
This commit also includes other minor fixes around CustomRuntime which was getting in the way of this specific issue
Added lookup for _HANDLER env variable
Added few tests (will need more)
Added support for Iterable for reactive functions
Resolves#662
Prior to this it was based on existance of AWS_LAMBDA_RUNTIME_API env variable which turned out to be not very reliable since it is present in Java 11 runtime
With this commit it simple ensures that the handler is neither FunctionInvoker nor AbstractSpringFunctionAdapterInitializer
Resolves#673
I've faced the "The key must start with a letter and can only contain letters, numbers, and underscores." issue in the AWS lambda. So both _HANDLER and spring.cloud.function.definition were not enabled to be added as environment variables. Let me know your thoughts.
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
