- 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
- Add schema server implementation
- Add schema client abstraction
- Add schema client implementation for own schema registry server
- Add schema client supporting Confluent schema registry
- Add Avro-based message converter supporting a static schema resource
- Add Avro-based message converter with schema evolution support, via
schema registry client.
- On serialization, the converter register writer schemas with the schema
registry server and augment the content type of outbound message with
schema information.
On deserialization, the reading converter will fetch the schema from the server
if not available locally.
Use class information if schema is not specified
In the case of SpecificRecord and Reflective readers/writers, the class information can be used instead
Make subtype prefix configurable and shorten the subject
- Subtype prefix is now configurable and subject is the lowercase schema name
- Enhance/correct javadoc
Refine AbstractAvroMessageConverter
- distinguish between writer and reader schema when reader is created
Add schema registry and schema registry client docs
Fixes#520Fixes#458 (for non-reactive binders)
Adds spring-cloud-stream-reactive module.
Introduces support for declarative @StreamListener and @Input and @Output annotated parameters.
Add StreamListenerArgumentAdapter and StreamListenerResultAdapter for wrapping bindable inputs
and outputs when passing arguments to declarative @StreamListener.
Adds support for using reactive types (Flux/Observable) with traditional binders.
Introduce FluxSender and ObservableSender for handling multiple streaming outputs per method.
Ensure that errors are caught and logged.
Fixing constructor assertions and Javadoc
Addressing PR comments
- rework @Input/@Output parameter validation
- renamed StreamListenerArgumentAdapter to StreamListenerParameterAdapter
- ensure that parameter direction is accounted for in the current adapters
Fixes#505
The goals are twofold: to simplify the registration of new converters and
to add some consistency to the conversion process, and align them with the
way converters are used in generic Spring Messaging listeners, by describing
two possible transformations: inbound, message (including contentType)->targetClass,
and outbound payload+headers -> message. The idea is for the two
transformations to match the input and output directions of the bound channels.
List of changes:
- Create and configure input/output channels distinctly - reflected
in the definitions of `BindableChannelFactory` and `MessageChannelConfigurer`;
- Replace AbstractFromMessageConverter with bidirectional converters;
- Use the channel direction (input/output) to determine whether
`toMessage` or `fromMessage` will be invoked;
- Use contentType support from `AbstractMessageConverter` to map
converters to mime types instead;
Making converters more robust
Addressing comments
Convert content type headers to String before serializing
Addressing further PR comments
Handle common aspects of message-channel binders:
- added generic, customizable ReceivingHandler and SendingHandler
- made doBindProducer delegate to a series of template methods
- made doBindConsumer delegate to a series of template methods
- moved partitioning to an interceptor, thus fixing #493
Removed unused manual ack handling
