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 approach simplifies the existing request handlers while also fixing the invocation model to ensure AC is not created multiple times and ExecutionContext is properly propagated via Message headers
The old request handlers are deprecated
Documentation updates as well as tests
Resolves#437
This is the current statement
>SpEL evaluation context’s root object is the actual input argument, so in he case of Message<?> you can construct expression that has access to both payload and headers (e.g., spring.cloud.function.routing-expression=headers.function_name).
This is the corrected one
>SpEL evaluation context’s root object is the actual input argument, so in the case of Message<?> you can construct expression that has access to both payload and headers (e.g., spring.cloud.function.routing-expression=headers.function_name).
```diff
-so in he case...
+so in the case...
```
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
