Added implementation of JsonMessageConverter which is initialized with JsonMapper so it can delegate to Jackson or Gson based on property setting and/or availability of the underlying library.
Resolves#476
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()`
