Fixes https://github.com/spring-projects/spring-integration/issues/3276
The `onErrorResume` for the `MessagingGatewaySupport.doSendAndReceiveMessageReactive()`
was in wrong place: only for the `buildReplyMono` which works only
when an outbound flow is fully based on reactive channels.
With a regular direct channel we can get an exception from the
`sendMessageForReactiveFlow` which is not covered with the mentioned
`onErrorResume` for the error handling on the configured `errorChannel`
Cherry-pick to `5.2.x & 5.1.x`
Fixes https://github.com/spring-projects/spring-integration/issues/3266
It turns out that `AnnotationGatewayProxyFactoryBean.onInit()` implementation
parses a `@MessagingGateway` attributes ignoring possible properties
population by setters.
This way a Java DSL `GatewayProxySpec` becomes useless since all
its options are overridden by default values from a synthesized
`@MessagingGateway`.
Also it is inconsistency when we declare an `AnnotationGatewayProxyFactoryBean`
as regular bean, but then called setters are ignored
* Add `protected` getters into `GatewayProxyFactoryBean` for all
the properties which can be overridden by annotation attributes
* Fix `AnnotationGatewayProxyFactoryBean` to consult with those getters
before populating a property with value from the annotation
**Cherry-pick to 5.2.x**
* Introduce a `ReceiveMessageAdvice`
* Deprecate an `AbstractMessageSourceAdvice` in favor of
`default` method in the `MessageSourceMutator`
* Move a `applyReceiveOnlyAdviceChain()` logic into the `AbstractPollingEndpoint`:
now both `PollingConsumer` and `SourcePollingChannelAdapter` can use
`ReceiveMessageAdvice`
* Introduce a `SimpleActiveIdleReceiveMessageAdvice` based already
on the `ReceiveMessageAdvice` and deprecate a `SimpleActiveIdleMessageSourceAdvice`
which is fully replaceable with newly introduced `SimpleActiveIdleReceiveMessageAdvice`
* Add `@SuppressWarnings("deprecation")` for those out-of-the-box `ReceiveMessageAdvice`
implementation which still use an `AbstractMessageSourceAdvice` for
backward compatibility
* Document a new feature and give the `MessageSourceMutator` a new meaning
* * Fix language in the `polling-consumer.adoc`
* Use a SimpleJsonSerializer in the FileSplitter
* To avoid extra dependency for Jackson when we
serialize `FileSplitter.FileMarker` to JSON, use
a `SimpleJsonSerializer` instead.
* Fix `SimpleJsonSerializer` to escape a `\` symbol from property values
since it is used for quoting string values in the final JSON
* * Document the change
Fixes https://github.com/spring-projects/spring-integration/issues/3253
The `IntegrationFlowBeanPostProcessor` uses a `containsBean()`
and then `getBeanDefinition()` to be sure that we don't override already
existing bean even if it is created in the parent(s) context.
The problem that `containsBean()` check the hierarchy, but `getBeanDefinition()`
doesn't.
So, we fail with `NoSuchBeanDefinitionException` if bean exists in the parent ctx
* Introduce an utility `IntegrationContextUtils.getBeanDefinition()` to
scan `BeanFactory` recursively for `BeanDefinition` for the requested `name`
* Use this tool in the `IntegrationFlowBeanPostProcessor` logic
**Cherry-pick to 5.2.x & 5.1.x**
* Add `ReactiveMessageSourceProducer`
The `ReactiveMessageSourceProducer` wraps a provided `MessageSource`
into a `Flux` for subscription in the `subscribeToPublisher(Publisher<? extends Message<?>>)`
to make a source polling feature fully based on a reactive, on demand solution
* Introduce a `IntegrationReactiveUtils` replacing existing `MessageChannelReactiveUtils`
with more functionality
* Replace a deprecated `MessageChannelReactiveUtils` with a new `IntegrationReactiveUtils`
* Test and document the feature
* * Fix Docs typos
* * Remove unused imports from `MessageChannelReactiveUtils`
* * Fix JavaDoc copy/paste artifact
- add a module to suppress legacy metrics from the Integration Graph
- move graph tests package to match src/main
Fix missed deprecation and checkstyle.
More deprecations and remove GraphLegacyStatsNullModule.
* Revert GRAPH_VERSION.
* Fix JavaDocs warnings
* Fix `MBeanExporterParserTests`
Fixes https://github.com/spring-projects/spring-integration/issues/2788
* Introduce a `MessageProducerSupport.subscribeToPublisher(Publisher<Message<?>>)`
for components which produces `Flux` for data from their source
* Such a component is auto-stopped when subscription to that `Publisher` is canceled
* Implement a `MongoDbChangeStreamMessageProducer` based on the reactive support for
in Spring Data MongoDb
* Implement a Java DSL for `MongoDbChangeStreamMessageProducer`
* Disable a test for change stream since it requires server of version 4.x started with 'replSet' option
* Add `MongoHeaders` for change stream events
* Change `MessageProducerSupport` to use a `takeWhile((message) -> isRunning())`
instead of storing a `subscription` from a callback
* Document new features
* Remove trailing whitespaces
* Doc Polishing.
* Increase latch timeouts for `RedisLockRegistryLeaderInitiatorTests`
* Some RMI tests fail with different outcome because an RMI registry might be
available on default `1099` port.
Fix them to not rely on that port
Resolves https://github.com/spring-projects/spring-integration/issues/3230
Previously, methods with the same name as `Lifecycle` methods were unconditionally ignored.
- Use logic similar to `ControlBusMethodFilter` to explicitly compare the candidate Method
to those on `Paused` and `Lifecycle` and only ignore those.
- Explicitly disallow these methods when named - previously the check was only performed
if no method name was supplied.
* - reinstate `Pausable/Lifecycle` methods if explicitly requested.
- log `Pausable` methods that are not candidates.
* - Fix typo in test method.
**Cherry-pick to 5.2.x**
* Add more Kotlin DSL for sub-flows
* Introduce `KotlinSplitterEndpointSpec`, `KotlinEnricherSpec` &
`KotlinFilterEndpointSpec` to avoid an explicit use of `IntegrationFlow` usage
from Kotlin DSL
* Fix `AbstractKotlinRouterSpec` to extend `ConsumerEndpointSpec` for access
to more endpoint options as it is with Java DSL for similar specs
* Introduce a `KotlinIntegrationFlowDefinition.publishSubscribe()`
for a `BroadcastCapableChannel` and `vararg` of `KotlinIntegrationFlowDefinition` builders.
This allows us to not introduce a `BroadcastPublishSubscribeSpec` wrapper for Kotlin
and let us to remove `publishSubscribeChannel()` DSL methods for `PublishSubscribeSpec`
since it is covered with the `publishSubscribe(PublishSubscribeChannel())` and
respective set of sub-flows in Kotlin DSL as subscribers
* Use new Kotlin specs in the `KotlinIntegrationFlowDefinition` instead of their
Java variants
* * Mention `kotlin-dsl.adoc` in the ToC
* Fix JsonToObjectTransformer for ClassNotFoundEx
Related to https://github.com/spring-projects/spring-integration/issues/3223
The `JsonToObjectTransformer` consults `JsonHeaders` first and tries to build
a `ResolvableType` from other type headers which may be just a string identifications.
In this case a `ClassNotFoundException` could be thrown if a `ResolvableType` cannot
be build against non-class identificators
* Add `valueTypeExpression` option to the `JsonToObjectTransformer` to let to
build a `ResolvableType` using any possible custom logic, e.g. resolving
target classes from some registry using their ids from the mentioned headers
**Cherry-pick to 5.2.x**
* * Fix English language mistakes
* Upgrade to Spring Data Moore-SR6
* Fix `TransactionHandleMessageAdvice` and `TransactionInterceptorBuilder`
for deprecations in the `TransactionInterceptor`
* Fix `TransactionHandleMessageAdvice` and `TransactionInterceptorBuilder`
consumers to expose new `TransactionManager`-based options and
deprecate `PlatformTransactionManager`-based
* Fix failing JMS tests to reuse an ActiveMQ Connection Factory with a
`trustedPackaged(*)`
**Cherry-pick to master**
# Conflicts:
# build.gradle
# spring-integration-core/src/main/java/org/springframework/integration/dsl/ConsumerEndpointSpec.java
# spring-integration-core/src/main/java/org/springframework/integration/dsl/PollerSpec.java
# spring-integration-core/src/main/java/org/springframework/integration/transaction/TransactionHandleMessageAdvice.java
# spring-integration-core/src/main/java/org/springframework/integration/transaction/TransactionInterceptorBuilder.java
Fixes https://github.com/spring-projects/spring-integration/issues/3223
The `json__TypeId__` header may have a value which cannot be resolved to the `Class` in the current classpath
So, skip `ResolvableType` building logic until we really sure that end-user wants to map JSON headers
* WARN a build exception that we can't load a class for the `json__TypeId__` when we try to build a `ResolvableType`
in the `DefaultAmqpHeaderMapper`
* Document the negation feature for JSON headers
**Cherry-pick to 5.2.x**
* Add Kotlin wrappers for router specs
To avoid casting and extra logic logic in the end-user code,
it is better to provide Kotlin-specific API to let end-users to
do whatever is really dictated by API and don't think about specific types to cast
* * Fix typos; code clean up
Fixes https://github.com/spring-projects/spring-integration/issues/3204
* Add an `intercept(ChannelInterceptor...)` method into `BaseIntegrationFlowDefinition`
to register one or more channel interceptors at the current flow position.
* refactor to reuse `InterceptableChannel` creation from `wireTap`
* document the new operator
* GH-3183: Add ReactiveRequestHandlerAdvice
Fixes https://github.com/spring-projects/spring-integration/issues/3183
* Introduce a `ReactiveRequestHandlerAdvice` with a `BiFunction<Message<?>, Mono<?>, Publisher<?>>`
logic to apply a `Mono.transform()` operator for a returned from the handler `Mono` reply
* Fix `WebFluxRequestExecutingMessageHandler` to return a `Mono.then()` instead of an explicit subscription -
it happens downstream anyway during reply producing with a proper error handling, too
* Demonstrate `ReactiveRequestHandlerAdvice` in the `RSocketDslTests` - without `retry()` it fails
* Add `ConsumerEndpointSpec.customizeMonoReply()` for convenience
* Document `ReactiveRequestHandlerAdvice` feature
* * Fix language in docs
* Add Reactive TX Manager support
* Change `TransactionInterceptorBuilder` and `TransactionHandleMessageAdvice` to reply
on a generic `TransactionManager`, so we can configure reactive one as well
* Change a `<transactional>` XML element to support a generic `TransactionManager` reference,
so we can configure reactive one as well
* Support `adviceChain` configuration for the `ReactiveMessageHandler` in the `ConsumerEndpointFactoryBean`
* Attemp to apply reactive transaction for the Reactive MongoDB channel adapter
* * Revert `MongoDbTests` change -
to support transactions we need the latest MongoDb server with replica enabled
* Document reactive transactions
* * Address PR reviews
It is better to poll message from `QueueChannel`
when ever a reactive request happens.
The `Mono.fromCallable()` operator does poll on subscription, not request
and caches the value.
However we may lose such a value in between.
* Use `Mono.create()` with its `monoSink.onRequest()` callback in the
`adaptPollableChannelToPublisher()` implementation to defer `inputChannel.receive()`
until an on demand request downstream
* GH-3192: pub-sub DSL for broker-backed channels
Fixes https://github.com/spring-projects/spring-integration/issues/3192
* Introduce a `BroadcastCapableChannel` abstract to indicate those `SubscribableChannel`
implementations which can provide a pub-sub functionality
* Implement a `BroadcastCapableChannel` in broker-baked channels with pub-sub option
* Introduce a `BaseIntegrationFlowDefinition.publishSubscribeChannel()` based
on the `BroadcastCapableChannel` and `BroadcastPublishSubscribeSpec` to let to
configure sub-flow subscribers in fluent manner
* * Add some JavaDocs and document new feature
* * Show the channel bean definition in the doc
* Fix typo
To support `onErrorContinue()` logic for the plain `Subscriber`
we need to wrap its `onNext()` into a `try..catch` and respective
`errorHandler` in the `ReactiveStreamsConsumer`
https://build.spring.io/browse/INT-MASTERSPRING40-978
Investigate a behaviour for `ReactiveStreamsConsumer`
when we use a plain `Subscriber` directly instead of `doOn...` callbacks.
It looks like there is some race condition when the data can be consumed
upstream, but there is no consumer downstream ready yet
* GH-3155: Add support for Java DSL extensions
Fixes https://github.com/spring-projects/spring-integration/issues/3155
Provide an `IntegrationFlowExtension` for possible custom EI-operators
in the target project use-cases.
* * Move `IntegrationFlowExtension` tests ot its own test class
* Make all the `IntegrationComponentSpec` ctors as `protected` for possible custom extensions
* Make some `BaseIntegrationFlowDefinition` methods and properties as `protected` to get them
access from the `IntegrationFlowExtension` implementations
* Document the feature
* * Fix language and typos in docs
* * Add `protected` to one more `GatewayEndpointSpec` ctor
* Add JavaDocs to `GatewayEndpointSpec` methods
* * Add `protected` to one more `JmsPollableMessageChannelSpec` ctor
Fixes https://github.com/spring-projects/spring-integration/issues/3157
* Fixed issue with sequences not being popped when Output processor returns a message.
* Updated documents and added additional Checks to the testcase to ensure proper `popSequence` is done.
* Updated documents and added corrected code formatting
* Updated documents and used headerAccessor Constants for matching headers
* Clean up code style
* Improve docs for the feature on the matter
* Gradle 6.1.1
* MongoDb 4.0
* Other Spring dependencies to `BUILD-SNAPSHOT`
* Fix MongoDb tests according latest Spring Data
* State in the docs that both MongoDb driver are `optional` now in the dependencies
* Populate a JsonHeaders.RESOLVABLE_TYPE on reply
Fixes https://github.com/spring-projects/spring-integration-samples/issues/277
In the `AbstractAmqpOutboundEndpoint` the `JsonHeaders.RESOLVABLE_TYPE`
from request message is copied to reply message making inconsistency downstream.
The `JsonToObjectTransformer` consults first a `JsonHeaders.RESOLVABLE_TYPE`
and deserialize payload to wrong type
* Fix `DefaultAmqpHeaderMapper` to populate a `JsonHeaders.RESOLVABLE_TYPE`
alongside with other `JsonHeaders` populated from the reply AMQP message.
This way a `JsonHeaders.RESOLVABLE_TYPE` from request message won't have effect
* To get access to classes, supply `AbstractHeaderMapper` with a bean factory `ClassLoader`
* Introduce a couple utility methods into `JsonHeaders` for building a `ResolvableType`
**Cherry-pick to 5.2.x**
* * Fix code formatting for arguments wrapping
Fixes https://github.com/spring-projects/spring-integration/issues/3152
The upstream `gatherResultChannel` header has been missed when we produced a reply from nested scatter-gather
Added Test Case for Nested Scatter Gather test
Simplified the the test cases and added author in changed cases
Corrected codestyle issue in Travis CI
Removed additional OriginalReplyChannel and originalErrorChannel in Headers.
Added additional not to be executed line of code in test case.
Restored OriginalErrorChannel Header and removed error handling related fixes
* Clean up code style and improve readability
**Cherry-pick to 5.1.x & master**
* Migrate `RouterTests` to JUnit 5
