- refactoring of BeanFactoryAwareFunctionRegistry to eliminate the need for FunctionType as it takes certain assumptions that are no longer valid
- adding support for multiple acceptedOutputTypes to FunctionCatalog
Resolves#388
- 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
- Added initial implementation of RoutingFunction which is bootstrapped optionally based on setting ‘spring.cloud.function.routing.enabled’ property to true.
- Added initial documentation and tests
Resolves#238
* 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
BeanFactoryPostProcessor that depends on FunctionCatalog is present.
On application context refresh, BeanFactoryPostProcessors are
invoked before registering BeanPostProcessor(s).
If a BeanFactoryPostProcessor that depends on FunctionCatalog is present,
then when ContextFunctionCatalogAutoConfiguration tries to fetch
all functional beans (Function/Supplier/Consumer), the creation of beans
where no default constructor exists fails as
AutowiredAnnotationBeanPostProcessor hasn't been registered yet.
Initialing BeanFactoryFunctionCatalog on ApplicationReadyEvent
delays the collection of functional beans to an even later point in
the lifecycle.
fixes#352
Fix test name
Switch to use SmartInitializingSingleton
Resolves#353
