- 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
- 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
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
Simplified FunctionCatalog structure by no longer registering the actual target function since it is available in wrapper anyway.
Cleaned up logic in RequestProcessor
Fixed NPE due to the missing main class - a condition that could be cause my missconfiguration
Added additional assertions
Added more descriptive error message
Added MAIN_CLASS system property to the search path
Added tests
Resolves#350
- Enhanced HTTP endpoint mapping support for 'functional form' context configuration ensuring it can register multiple endpoint to maintain the same behaviour as with regular application context
- Additional consolidation around Function Catalog
- Added identical test for functional and non-functional form endpoint configuration.
Resolves#293
- 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
