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.
Ensured that the default instance of ObjectMapper is created in the event ObjectMapper configuration is missing (i.e., JacksonAutoConfiguration) in AWS adapter
Resolves#188
Some tests still ignored.
Also adds draft functional bean registration support. The AWS sample
is using that now (it starts up 4x faster in AWS). To activate the
functional beans user has to supply a main class of type
ApplicationContextInitializer.
Flux.from() is cheap and can be used to marshal the inputs everywhere
internally. With this change users ought to be able to register any
function of any Publisher type.
The current implementation of SpringBootKinesisEventHandler only handles
non-aggregated events. Attempting to process aggregated events caused
ungraceful failure.
This commit fixes that by de-aggregating any events before performing
conversion. Non-aggregated events are still handled transparently.
In addition, detection of Message<T> input is performed, and
output messages are wrapped accordingly.
This results in a better experience for users because the consumer
that they write is only applied to a Flux that is subscribed to
by the framework once. It gives better control over the flow of
foos, e.g. if some component wants to subscribe on a thread.
Makes it possible to support other "function" types in the future.
The user is always taking a risk with the lookup that the object
returned has the generic type desired (but that hasn't changed
with this commit). FunctionCatalog is a lot simpler as a result
and also a lot more flexible.
User can extend SpringBootApiGatewayRequestHandler instead of the
generic SpringBootRequestHandler. It ties the code to AWS and the
API Gateway, but at least it supports the incoming data fully.
Fixes gh-111, closes gh-136
Lambdas generally only deal with single values anyway, but for
consistency we should return similar results from a Lambda handler
as from an MVC handler in s-c-f-web.
