For complex cases where deep hierarchies are used there was still an issue with the fix in #473.
By adding TypeResolver library we essentially simplify our discovery process
Resolves#474
Similar to the way we allow multiple functions to be listed with 'definition' property, this enhancement allows several functional classes to be deployed
Resolves#461
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
- Re-enable, clean and improve special handling for collection/array output type
- Add tests to validate and demonstrate the differences in special handling of collection of Messages ve collection of non-Messages
Resolves#464
- Added logic to wrap custom (user) message converters with NegotiatingMessageConverterWrapper
- Removed 'addDefaultConverters' flag from ContextFunctionCatalogAutoConfiguration as it is more confusing then useful
- Added test which uses wild card accept content-type with several converters available to ensure the appropriate one is used
- Made NegotiatingMessageConverterWrapper package private and moved it and it's test to a contex.config package
Resolves#462
Modified invocation model of the reactive consumer to ensure it provides reasonable continuation path via MonoIgnoreElements (Mono.. . .then())
Resolves#453
- Added generic FunctionInvoker capable of handling the request generically without requiring user to implemen specific AWS request handler
Resolves#434
- Ensured that FunctionClassUtils performs additional check to ensure that located star class is SpringBootApplication
- Added additional lookup to look for Main-Class if nothing was found in Start-Class primarily to support Azure
- Updated Azure samples
- Updated documentation
Resolves#431
- Fixed logic behind discovery of Start-Class which didn't work well with some JVMs
- Isolated the Start-Class in a separate utility class as it is going to be used elsewhere
Resolves#421
Ensured that we check for the output type and see if and what type of conversion needs to be applied. If output is already a message with payload byte[], then no conversion is necessary
Resolves#419
* Fix spring-integration sample
* Added discoverFunctionTypeFromClass() method to FunctionTypeUtils
* A `FactoryBean` may produce a function instance as well.
Add a logic into `BeanFactoryAwareFunctionRegistry` to discover a function type from the `FactoryBean.getObjectType()`
Fixed discovery of functions to ensure that even in cases where default function is found but it's type can not be determined such function is discarded. This effectively ensures that if the actual instance does not match the declared type such function is not treated as function.
Resolves#409
