JIRA: https://jira.spring.io/browse/INT-3073
Add `FluxAggregatorMessageHandlerTests`
* Add `FluxAggregatorMessageHandlerTests`
* Fix `FluxAggregatorMessageHandler` for the default `messageForWindowFlux`
to rely on the `publish().autoConnect()` to build a target `Flux` for
window and also copy headers from the first `Message` in the window.
Looks like `switchOnFirst()` doesn't work somehow with windows or I just
don't use it properly, although it isn't clear how to continue chain but
get the whole `Flux` as a single entry for message payload
* Add more tests for `FluxAggregatorMessageHandlerTests`
* Fix `AbstractMessageSplitter` to cast properly a primitive array
* Implement `Lifecycle` in the `FluxAggregatorMessageHandler`
* Add JavaDocs into the `FluxAggregatorMessageHandler`
Javadoc polishing
* GH-2880: Handle `Pausable` in Control Bus
Fixes https://github.com/spring-projects/spring-integration/issues/2880
* Refactor `ControlBusMethodFilter` to handle `Pausable` managed operations
* Optimize and internal `ControlBusMethodFilter.filter()` logic to rely
on the `MergedAnnotations`
* Modify `EnableIntegrationTests` to test new functionality and document
the feature
* * `ControlBusMethodFilter` to deal with plain `Lifecycle` impls as well
Since SF has deprecated `StandardAnnotationMetadata` ctors in favor
of factory method, we can't extend it any more to adapt annotation
attributed by the map generated from the XML attributes
* Introduce an `AnnotationMetadataAdapter` to request a
`getAnnotationAttributes()` implementation which is only a method used
in the target `registerBeanDefinitions()` implementations
* Use a new `AnnotationMetadataAdapter` whenever the `StandardAnnotationMetadata`
has been used before
* Move SF dependencies to the latest BUILD-SNAPSHOT
To avoid class loader issues it is better to align Spring Data
dependencies with SF version we use explicitly.
This way we don't have a `ClassLoader` issue when a newly introduced
`TransactionManager` might not be visible from the previous versions
* Fix code style warnings in the `TransactionSynchronizationFactoryBean`
* Use `JavaUtils` in the `TransactionSynchronizationFactoryBean` to
decrease code complexity
* * Fix CQ Gemfire tests for upgrades compatibility
* For better performance and consistency use a `MergedAnnotations` in
the `MethodAnnotationPublisherMetadataSource` instead of
`AnnotatedElementUtils`
* Remove deprecated API from the `PublisherMetadataSource` hierarchy
* use equals
* inner assignment
* local before return
* unnecessary locals
* catch and throw
* uninstantiable with no statics
* implement `Serializable` in `Comparator` to enable `TreeMap` serialization
* exceptions as flow control
Fixes https://github.com/spring-projects/spring-integration/issues/2908
* make sure the attribute is taken into account in @Header annotation
* remove useless spaces according to checkstyle rules
* make sure the expression attribute is taken into account as well in @Payload annotation
* Add initial support for RSockets
* Add `spring-integration-rsocket` module and respective dependencies
* Implement `RSocketOutboundGateway` based on the Spring Messaging
`RSocketRequester`.
This component supports dynamic RSocket properties via expressions
against request message.
to handle `Publisher` for requests, it must be present in the request
message `payload` instead of `FluxMessageChannel` upstream, since the
last one just flattens events to be handled in the `MessageHandler` one
by one.
The result `Mono` is subscribed downstream in the `FluxMessageChannel`
or directly by the `AbstractReplyProducingMessageHandler`.
If result is a `Flux` it is just wrapped into the `Mono` to be processed
downstream by end-user code.
The point is that these request/replies are volatile and live in the
particular context meanwhile a `FluxMessageChannel` is long living
publisher in the application context boundaries.
* The `RSocketOutboundGatewayIntegrationTests` is an adapted copy of
`RSocketClientToServerIntegrationTests` from Spring Messaging
* Add `doOnError()` into the `Flux` created in the
`AbstractMessageProducingHandler` for `Publisher` replies
* * Use singular for the `RSocket` term
* Use no-op `Consumer` for the `strategiesConfigurer` and
`factoryConfigurer` in the `RSocketOutboundGateway` and also
`Assert.notNull()` in the appropriate setters to avoid null check during
`RSocketRequester.builder()` initialization
* Use `TcpServer.create().port(0)` in the
`RSocketOutboundGatewayIntegrationTests` to allow to select free OS port
and bind into it.
The selected port is used later for client configuration in the
`RSocketOutboundGateway` bean definition
* * Change `RSocketOutboundGatewayIntegrationTests.PORT` to lower case
* Fix `AbstractMessageProcessingTransformer` to react for the
`AbstractIntegrationMessageBuilder` invocation result and don't wrap it
into the `Message`
* Demonstrate functionality in the `CacheRequestHandlerAdviceTests`
* Polishing and Docs
* Fix JavaDocs warnings
Doc polishing.
* INT-4299: Add AbstractMailReceiver.autoCloseFolder
JIRA: https://jira.spring.io/browse/INT-4299
* Optimize `AbstractMessageSource` do not evaluate headers when polling
result is `null`
* Optimize `MailReceivingMessageSource` do not wrap polling result to
the message: the `AbstractMessageSource` will do that later
* * Fix JavaDocs
* Document `autoCloseFolder` option
* GH-2765: Add discardChannel for splitter
Fixes https://github.com/spring-projects/spring-integration/issues/2765
When encountering empty collections, splitter should be able to send
the result to a discard channel.
Currently, when encountering an empty collection,
the splitter ends the flow.
Some use-cases may rely on a custom split function which may returns
empty collections.
These use-cases should be able to define a discard channel
so they can proceed with a possible compensation flow.
* Add `discardChannel` option to the `AbstractMessageSplitter`
* Delegate `discardChannel` population from everywhere it is possible:
DSL, XML, `AbstractMessageSplitter` extension like `FileSplitter` etc.
* Fix `FileSplitterTests` for broken charset
* Document new feature; fix some typos and out-dated code sample
* * Fix `SplitterFactoryBean` for NPE on the `discardChannelName`
propagation
* * Check `this.discardChannel` first
* `Assert.state()` in `doInit()` for mutual exclusiveness
https://build.spring.io/browse/INT-MASTER-1479
The `MicrometerCustomMetricsTests` and `MicrometerMetricsTests` close
an application explicitly in the test, so we can't handle test events
properly any more.
Therefore use only `DependencyInjectionTestExecutionListener` excluding
all others together with the `EventPublishingTestExecutionListener`
The `TcpConfigInboundGatewayTests` don't need to use a static holder
for the application context at all and, therefore, there is nothing to
close in the `@After` any more
There is reason to close an application context in the
`StoredProcOutboundChannelAdapterWithinChainTests`.
Other tests must take care about clean embedded DB before their start
Fixes https://github.com/spring-projects/spring-integration/issues/2754
For better end-user experience when we have `@Bean` declared for a
channel it is good to have a `MessageChannel` based
`RouterSpec.channelMapping` for possible traceability and code
navigation in the IDE
* GH-2873: Preserve mapping order in the router
Fixes https://github.com/spring-projects/spring-integration/issues/2873
Sometime it is important to map to most specific exception instead of
its super class.
* Use `LinkedHashMap` for mapping keys in the
`ErrorMessageExceptionTypeRouter`, as well as in its
`AbstractMappingMessageRouter` superclass.
Since we don't do that internal map modification, there is no reason to
worry about concurrent access: we just replace an internal instance
atomically with a new `LinkedHashMap` every time we modify a mapping
for router
**Cherry-pick to 5.1.x**
* * Fix `RouterSpec.RouterMappingProvider` to `LinkedHashMap` as well
* * Fix `RouterTests` for proper mapping order
* Polishing for `AbstractMappingMessageRouter` hierarchy, so we don't
use `protected channelMappings` field access any more
* Short-circuit methods for lambdas from annotation
When we have a `@ServiceActivator` or any other messaging annotations
on `Function` or `Consumer` `@Bean`s, there is a restriction when we
can't use lambdas because of target method argument type erasure in Java.
* Use a `@Bean` method return to determine the target function argument
type and wrap the call into the `LambdaMessageProcessor`.
In this case we call the target method directly after possible payload
conversion according expected generic type for `Function` or `Consumer`.
There is just no reason to go a `MessagingMethodInvokerHelper` route
for this lambda variants
* Apply the short-circuit algorithm for Kotlin lambdas as well
* Make some refactoring and improvements to `ClassUtils`
if favor or similar API in the SF `ClassUtils`
* Fix `No beanFactory` warning for the `ExpressionCommandMessageProcessor`
* * Resolve Checkstyle violations
* * Fix `resolveAttributeToBoolean()` argument name to be generic
* Fix typo in the exception message for `IntegrationFlowDefinition.get()`
* * Revert `ClassUtils.resolvePrimitiveType()` logic: an existing in SF
does exactly opposite one
* Do not fix urls for the `http://apache.org/xml/features` when we
configure XML components
* Do not fix urls for localhost and fake links in tests
* Fix all the dead links in docs
* Support generics in the `JsonToObjectTransformer`
* Deprecate `JsonObjectMapperAdapter` if favor of `default` methods in
the `JsonObjectMapper`
* Introduce `JsonObjectMapper.fromJson(Object, ResolvableType)` to
support generics during deserialization
* Add `JsonHeaders.RESOLVABLE_TYPE` header handling for the
`ResolvableType` management
* Add `ResolvableType` argument into the `JsonToObjectTransformer`
* Change the `JsonToObjectTransformer` logic to consult request message
headers first
* Add `ResolvableType`-based factory method into the `Transformers`
* Document the change
* * Use `0` for conversion to array for headers to remove
in the `JsonToObjectTransformer`
