This is specifically relevant to the way Kotlin represents types. For example List<Message> resolves to List <? extends Message> which becomes the WildCard unlike in Java
Resolves#1260
This way just like with any other function, Kotlin initialization, type discovery etc will be performed on function lookup
This will also ensure that order of various post processors doesn't get in the way.
Resolves#915
Use suspendCoroutineUninterceptedOrReturn to avoid using not fully implemented Function2.reflect()
Mapping of Function, Consumer and Supplier to kotlin suspend flow lambda
Fix MR review
Resolves#655
Fix the way FunctionTypeUtils deals with Kotllin function when it attempts to discover their type.
Basically it checks if function-name + '_registration' nean exists and if so it skip discovery and uses the types available in FunctionRegistration which for Kotlin scenarios will always exist.
Resolves#632
- 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
