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[]
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
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
- Added generic FunctionInvoker capable of handling the request generically without requiring user to implemen specific AWS request handler
Resolves#434
* 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
- Added initial support for communicating routing instructions via SpEL thru both message headers and application properties
- Added support for communication function definition via application properties
- Added additional tests and updated documentation
Resolves#408
- 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
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
