This addresses the issue of dropped Message headers in the event where input is a Message but input conversion is not necessary
while Message contains headers that require explicit propagation (e.g., scf-sink-url, scf-func-name)
Resolves#588
This fix also introduces new Function property 'accept' with no default value which implicitely would default to application/json unless the output type of the function is String at which point it would default to text/plain. However, if it was explicitely set in FunctionProperties it will be used regardless of the function output type.
Resolves#587
Added support to JsonMessageConverter to pass string as is if input type is String
Added guard condition to RSocketListenerFunction to avoid NPE if target function can not be discovered
Add test in AWS to showcase type conversion
Fix AWS FunctionInvoker to delegate to effectively delegate type conversion to the native mechanism of spring-cloud-function
Resolves#562
This fix insures that 'spring.http.converters.preferred-json-mapper' property is only used as mechanism to break tie in the event both jackson and gson are available in classpath or AC
Resolves#537
Given that we now can auto-discover function type from provided target object, this fix will fail function registration if provided type is not compatible (assignableFrom. . .)
Resolves#531
It is really not needed as it does not add much value other then allows user to cast POJO function to its actual type. The reality is that the actual goald of POJO function is to make sure they can be looked at as plain Functions.
Resolves#514
- Add 'contentType' property to ExporterProperties to assist SupplierExporter with delegating it to function catalog
- Add additional logging and testing
- Change JsonMapper to abstract class providing special handling of conversion of Json Sting to byte[]
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
