JIRA: https://jira.spring.io/browse/INT-4541
Add test case to reproduce.
The gateway correctly sets up the `errorChannel` header so that a downstream
`MPEH` will send exceptions back to the gateway, but the `map()` function
did not check for an error message.
Check for an error message and throw the payload so that the `onErrorResume`
will route to the error channel.
* INT-4540: Use MessageHeaders in GenericHandler
JIRA: https://jira.spring.io/browse/INT-4540
For better end-user experience use a `MessageHeaders` in the
`GenericHandler` instead of plain `Map<String, Object>`
* * Fix `IntegrationFlowEventsTests`
JIRA: https://jira.spring.io/browse/INT-4538
* Add support for Jackson `TreeNode.size()` in the `AbstractMessageSplitter`
* Add overloaded `Transformers.toJson(ObjectToJsonTransformer.ResultType)`
* Modify test to verify Jackson `ArrayNode` use-case with the splitter
and aggregator
**Cherry-pick to 5.0.x**
JIRA: https://jira.spring.io/browse/INT-4539
The `IntegrationFlowBeanPostProcessor` doesn't check for prototype beans
and just override them in the application context with the singletons
* Since we can't in the DSL understand if provided object is a prototype
or not, we try to check for its bean definition by possible bean name.
Use `NamedComponent` for possible bean name to check.
* Remove `final` from the `IntegrationComponentSpec.get()` since its
result is not visible for CGI proxies when it is declared as a `@Bean`
and subsequent `getObject()` produces a new internal object
* Verify prototype beans with new test in the `IntegrationFlowTests`
**Cherry-pick to 5.0.x**
JIRA: https://jira.spring.io/browse/INT-4537Fixesspring-projects/spring-integration#2582
* Rename `ReactiveStreamsConsumer.messageHandler` property to the
`handler` for consistency with other `IntegrationConsumer` s
* Do not wrap `Subscriber` into the `MessageHandler` if that one is
already a `MessageHandler`
* Fix `MockIntegrationContext` for the logic around `ReactiveStreamsConsumer`
where it is not enough just replace a `handler`, but we also need to do
that with the `subscriber`.
Luckily the `MockMessageHandler` is also a Reactive `Subscriber`
* Clean up `MockIntegrationContext.beans` in the end of `resetBeans()`
* Improve `testing.adoc`
**Cherry-pick to 5.0.x**
If exception happens in the `callback.doWithInputStream(inputStream)`,
we don't close the `inputStream = session.readRaw(remotePath)`.
* Move the `InputStream.close()` to the `finally` block of the
`SessionCallback` action in the `RemoteFileTemplate.get()`
**Cherry-pick to 5.0.x and 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4479
For better user experience expose a `RequestEntity<?>` as a root object
for evaluation context for `statusCodeExpression` execution
* Allow Functions as Service Activators
* Fix `MessagingMethodInvokerHelper` to extract canonical method for the
`Function` and `Consumer` beans
* Demonstrate in test how `Function` and `Consumer` can be configured
with the Messaging annotations
* Don't mutate method argument
* Changed an Assert error message in the `FileReadingMessageSource` to make the requirements
when using an external scanner clearer, and added some explanatory comments.
* Removed use of 'local' to eliminate confusion.
* Added javadoc addendum
* Adding ChainFileListFilter constructors to behave like CompositeFileListFilter
Fixes https://github.com/spring-projects/spring-integration/issues/2569
Adding constructors in `ChainFileListFilter` matching super, so this class behave
like `CompositeFileListFilter` when using XML flow configuration.
* Fix import error
* Fix checkstyle
* Fix checkstyle
* Fix checkstyle
* Fix author name case
Remove unnecessary javadoc
* Fix code smell squid:S1155
* Add a simple test case for initializing filters with constructor
Fix code smell squid:S1192
* Add a simple test case for initializing filters with constructor
Fix code smell squid:S1192
* Fix missing import
* Spring AMQP 2.1 B-S and fix imports for moved classes
* Reactor GA
* SF-5.1 B-S and exclude `org.springframework` from all the
Spring Security dependencies
* the latest Hibernate and JPA and fix the test query for the
appropriate actual syntax
* latest SSHD and add required dependency for `sshd-sftp`
* latest Groovy and extra dependency for the `groovy-dateutil`
* latest Smack for XMPP and appropriate code fixes for compatibility
* Fix `StompIntegrationTests` to use `AFTER_EACH_TEST_METHOD`:
when session is disconnected on the server, we can't interact with it
anymore
Use the `RetrySynchronizationManager` instead of a `RetryListener`.
Fix `setAttributesIfNecessary` for gateway conversion errors (this, at least,
should be cherry-picked).
* Add `IntegrationFlowDefinition.nullChannel()`
When a `NullChannel` is used in the middle of the flow, it may be not so
obvious why our flow is stopped after accidentally added the next
endpoint
* For convenient add a terminal `nullChannel()` operator into the
`IntegrationFlowDefinition`
* * Add WARN about `NullChannel` subscription from the endpoints
* Fix a logic in the IntFlowDef.toReactivePublisher
* We may consider to start a `Publisher<Message<?>>` just from one
channel.
So, and an implicit `bridge()` to meet and internal `IntegrationFlow`
logic
* The `MessageChannelReference` and `FixedSubscriberChannelPrototype`
can't be converted to the reactive `Publisher`.
So, an implicit `bridge()` in between them and target `FluxMessageChannel`
NOTE: This maybe considered for back-port, but the workaround is
simple: just add extra `bridge()` after the mentioned channels
* * Allow `log()` before `toReactivePublisher()` and the same time fix
the problem with not resetted `implicitChannel` flag in the
`IntegrationFlowDefinition`
* INT-4523: Add DSL `convert(Class<> cls)` operator
JIRA: https://jira.spring.io/browse/INT-4523
* Change the `LambdaMessageProcessor` to rely on the `MessageConverter`
populated by the `IntegrationContextUtils.ARGUMENT_RESOLVER_MESSAGE_CONVERTER_BEAN_NAME`
This way all the Lambda-based handlers are going to work the same way
as POJO-based via `MessagingMethodInvokerHelper`
* Add `convert(Class<P> payloadType)` EIP-operator to perform similar
to POJO-based method invocation argument conversion
* * Fix `LambdaMessageProcessorTests` to inject a
`ConfigurableCompositeMessageConverter` from the mocked `BeanFactory`
* Make a `mappingJackson2MessageConverter.setStrictContentTypeMatch(true)`
* Also obtain an `ObjectMapper` from the `Jackson2JsonObjectMapper`
which is configured with the scanned possible Jackson modules.
in the `ConfigurableCompositeMessageConverter` do not try to convert
all the potential content without an appropriate JSON content-type
header
JIRA: https://jira.spring.io/browse/INT-4531
The `DelegatingSessionFactory` uses plain `Object` as key type
whereas the default `RotatingServerAdvice` does not.
* Change the type from `String` to `Object` in the `RotatingServerAdvice.KeyDirectory`
* Fix typos in the (s)ftp.adoc
**Cherry-pick to 5.0.x**
* Add Reactive mode for AbstractPollingEndpoint
* When `SourcePollingChannelAdapter.outputChannel` is a
`ReactiveStreamsSubscribableChannel`, use `Flux.generate()` for polling
* Refactor `AbstractPollingEndpoint` to remove redundant `Poller` class
in favor of lambda
* Extract `pollForMessage()` method to handle TX states instead of
`Poller` class previously
* * Rebase and fix conflicts
* Polishing for GatewayProxyFactoryBeanTests
JIRA: https://jira.spring.io/browse/INT-4307
Shut down the container (to close the connection) when a message-driven
endpoint is stopped while the application continues to run.
* INT-4317: JMS: dynamic deliverMode and timeToLive
JIRA: https://jira.spring.io/browse/INT-4317
* Add `deliveryModeExpression` and `timeToLiveExpression` properties
to the `JmsSendingMessageHandler` and expose them in the Java DSL and
XML components
* Add `setMapInboundDeliveryMode()` and `setMapInboundExpiration()`
`boolean` properties (default `false`) to the `DefaultJmsHeaderMapper`
for transferring `JMSDeliveryMode` and `JMSExpiration` into appropriate
`JmsHeaders.DELIVERY_MODE` and `JmsHeaders.EXPIRATION` headers
* Upgrade to latest Kotlin and AssertK
* Upgrade to Kotlin 1.2.61
https://build.spring.io/browse/INT-MASTERSPRING40-458/
We need to stop Inbound Channel Adapter first and only then wait for
the latch.
Otherwise there is a chance that new item is added to the collection
in between `latch.await()` and `stop()`
**Cherry-pick to 5.0.x**
JIRA: https://jira.spring.io/browse/INT-4525
Hard-coded 2 second delay is now configurable.
Also fix the logic for creating the SpEL evaluation context.
**cherry-pick to 5.0.x**
* Polishing according PR comments
Creating a EPHEMERAL_SEQUENTIAL node was being used to ensure the
Zookeeper connection had been established. These were never explicitly
removed, which led to tryLock effectively leaking zNodes until the
client was terminated. This in turn lead to an extremely large number of
ephemeral nodes being deleted whenever a long running service
terminated!
This fix replaces the creation of a node with a stat of "/" instead.
This has the desired effect of re-establishing the Zookeeper connection,
but is a read-only operation.
* Remove unused import
* Add Micrometer metrics capture for the
`PollableAmqpChannel` and `PollableJmsChannel`
* Polishing and optimization for the `AbstractPollableChannel.receive()`
**Cherry-pick to 5.0.x**
Make key/trust store types configurable; add a test with host violation.
* Fix some typos and code style in the related classed and docs
* Add asserts for the store type properties
JIRA: https://jira.spring.io/browse/INT-4527
Fixes https://github.com/spring-projects/spring-integration/issues/2543
- Add error handling within the scope of a transaction
- Add `retryDelay` and `maxAttempts`
- Include the delivery attempt header in the `ErrorMessage`
- Add `transactionalRelease()` methods to the DSL
Check context in `ContextRefreshedEvent`.
Complete test case; don't schedule for re-release after a successful send after a failure.
Use `identityHashCode` for deliveries map key - error flow might change the message `hashCode`.
Debug logging
Polishing; remove parameter from the `DelayerEndpointSpec.transactionalRelease()`
* Polishing some code style
- inconsistent use of internal `TimeUnit`
- `setPeriod()` applied the unit, but `getPeriod()` did not
This test failed...
```java
@Test
public void testTriggerConsistency() {
final DynamicPeriodicTrigger trigger = new DynamicPeriodicTrigger(10, TimeUnit.SECONDS);
trigger.setPeriod(trigger.getPeriod());
assertThat(trigger.getPeriod(), equalTo(10_000));
}
```
Change the trigger to use `Duration` and deprecate the other methods.
https://build.spring.io/browse/INT-MASTER-1165/
The test checks how much time have we spent for the process.
It's too hard to be precise in all the environment, especially on slow
CI servers
* Make some code style polishing in the `AggregatorTests`
https://build.spring.io/browse/INT-MASTERSPRING40-441
Even if we `stop()` a `SourcePollingChannelAdapter` that doesn't mean
that task-in-progress can't deliver its result to the source consumer.
* Wrap a list `add()` and iterator operations to avoid a
`ConcurrentModificationException`
