Resolves#691
- If the broker supports native serialization, then the serialization of the
outbound payload is not done by the binder's producer binding outbound message handler.
- At the consumer binding's inbound message handler, the extraction of embedded headers
is performed only for the byte[] payload (given the deserialization would have already
occurred at the broker level)
- Add correspoinding tests in Kafka binder implementation
- Rely on the received message type to decide on using out of the box deserializer (only
if byte[] message payload is received)
Fixes#686
Removing unused imports
Simplify the registration process
- rely on EntityScanPackages.register to properly merge registered packages
- add additional tests validating the process
- In AggregateApplication, support specifying commandline and environment properties based on namespace for each containing applications using namespace as prefix
- As usual, command line properties override the environment as well as the properties specified inside the application
- Set argumentClass to Object when using wildcard/generic types if the StreamListener method parameter for @Input annotated type uses wildcard/generic type, then set the argumentClass to `Object.class` instead of null.
Resolves#665
Address review comments
Fixes#660#661
* Fix an issue where aggregated applications were not enabling web endpoints
* Add spring-integration-jmx as mandatory dependency, so that SCSt applications
expose metrics by default;
* Remove `AggregatorParentConfiguration` as redundant
* Register a `PublicMetrics` instance for each aggregate, using a customized version
of SpringIntegrationMetricReader
- The aggregator builder parent sources and cmdline args can be passed via
- AggregateApplicationBuilder constructor
- AggregateApplicationBuilder parent() builder method
and, the cmd line args can also be passed via
- AggregateApplicationBuilder run() method
This PR supports passing all these options. The implementation sets `parentSources` and `parentArgs` by collecting the values from all the above options and use them when creating the parent context.
- Add test case to verify these scenarios
This resolves#626
Make sure to handle self-contained apps parentContext
- Always create parent context with the aggregatorParentConfiguration
- This will avoid other lifecycle beans inside the application context starting when
binding lifecycle beans are started.
Resolves#525
Address review comments
- BinderTypeRegistry will have empty binder types for aggregate applications
- Check if `SharedChannelRegistry` bean is in the context, then proceed with no binder type
This resolves#576
Support self contained aggregator app without binder dependency
- Check if the aggregator application is self contained (with both source and sink applications exist) and if so, avoid having the check to have binder in classpath at BinderFactoryConfiguration
- Given the aggregator parent context has binder configuration classes via `@EnableBinding`, enable all the auto configuration classes(excluding the binding configuration classes) as a parent for aggregator builder. This will have the aggregator parent to determine if the aggregator app is `selfContained` and set the parent context once all the app configurers are set
- Add tests
- Remove unused aggregator application methods
