- 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
* Handler extends AzureSpringBootRequestHandler with types
HttpRequestMessage and HttpResponseMessage (which are required by
Azure Functions for HTTP-triggered functions)
* Handler extracts request path, query string parameters as well as the
HTTP method from the HttpRequestMessage object and forwards them to
the function as message headers
* Handler creates an HttpResponseMessage with the response coming from
the called function
* Created unit tests accordingly
GH-317, Implement HTTP request-specific handler for Azure adapter
* Handler extends AzureSpringBootRequestHandler with types
HttpRequestMessage and HttpResponseMessage (which are required by
Azure Functions for HTTP-triggered functions)
* Handler extracts request path, query string parameters as well as the
HTTP method from the HttpRequestMessage object and forwards them to
the function as message headers
* Handler creates an HttpResponseMessage with the response coming from
the called function
* Created unit tests accordingly
GH-317, Implement HTTP request-specific handler for Azure adapter
* Handler extends AzureSpringBootRequestHandler with types
HttpRequestMessage and HttpResponseMessage (which are required by
Azure Functions for HTTP-triggered functions)
* Handler extracts request path, query string parameters as well as the
HTTP method from the HttpRequestMessage object and forwards them to
the function as message headers
* Handler creates an HttpResponseMessage with the response coming from
the called function
* Created unit tests accordingly
- Added support for injecting target execution context into the ApplicationContext in AbstractSpringFunctionAdapterInitializer, effectively making it available to all adapters (if one is provided)
- Added test, docs
Resolves#265
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.
