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
* 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
- 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
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.
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.
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.
