Fixes https://github.com/spring-projects/spring-integration/issues/2799
**Cherry-pick to 5.1.x & 5.0.x**
When `AnnotationGatewayProxyFactoryBean` is used for the one-way (`void`)
POJI method invocation and downstream processing is based on an
`ExecutorChannel`, the default `errorChannel` value from the annotation
is resolved to the empty string with is set to the target gateway proxy
and can not be resolved to the target bean eventually in the
`MessagePublishingErrorHandler` in case of exception
* Check `errorChannel` attribute for empty string and don't set it into
the `errorChannelName`.
This way the `MessagePublishingErrorHandler` will resolve to the global
`errorChannel` as expected.
* Fix MMIHelper for reinitialization
If we provide a custom `MessageHandlerMethodFactory`, the
`MessagingMethodInvokerHelper` obtains its bean and reinitialize a
`handlerMethod`, but it is done only for single, explicit
and provided method.
In case of `Function` or `Consumer` we use local names for methods to
extract, but this is not populated to properties of the
`MessagingMethodInvokerHelper`
* Change an internal `MessagingMethodInvokerHelper` logic to recreate
`InvocableHandlerMethod` instances based on the `MessageHandlerMethodFactory`
bean for all the methods scanned on the target.
* Populate a `handlerMethodsList` for the purpose above even if we have
only one candidate
* Fix `AggregatorParserTests` to reflect the current logic around
`handlerMethodsList`
* Prove that new logic works well with a custom `MessageHandlerMethodFactory`
bean in the `MessagingAnnotationsWithBeanAnnotationTests`
**Cherry-pick to 5.1.x**
* * Move CTOR to the proper place
# Conflicts:
# spring-integration-core/src/main/java/org/springframework/integration/handler/support/MessagingMethodInvokerHelper.java
# spring-integration-core/src/test/java/org/springframework/integration/config/AggregatorParserTests.java
Fixes https://github.com/spring-projects/spring-integration/issues/2776
Also see https://github.com/spring-projects/spring-integration/issues/2777
- reset the filter for the current file if the fetch fails
- implement `Lifecycle` and clear the `toBeReceived` queue and corresponding
filter entries
* Polishing - PR Comments **cherry-pick to all supported**
* Polishing
# Conflicts:
# spring-integration-file/src/test/java/org/springframework/integration/file/remote/StreamingInboundTests.java
# spring-integration-ftp/src/test/java/org/springframework/integration/ftp/inbound/FtpStreamingMessageSourceTests.java
# spring-integration-jdbc/src/test/java/org/springframework/integration/jdbc/StoredProcJavaConfigTests.java
Fixes https://github.com/spring-projects/spring-integration/issues/2770
Only create an evaluation context for header expressions if we actually
have header expressions.
* Some `AbstractMessageSource` refactoring to avoid unnecessary code and
some optimization
**Cherry-pick to 5.1.x**
* GH-2759: Fix CorrelationData.future
Fixes https://github.com/spring-projects/spring-integration/issues/2759
The outbound endpoints wrap user correlation data in a wrapper.
If the user data is a `CorrelationData`, we must delegate methods
involving the `Future<?>` and `returnedMessage` to the user data.
**cherry-pick to 5.1 and switch AMQP to snapshots**
* Polishing - remove redundant override.
* Add debug log with null correlation data
# Conflicts:
# spring-integration-amqp/src/test/java/org/springframework/integration/amqp/outbound/AmqpOutboundEndpointTests.java
* Updated Spring AMQP dependency to `2.1.5.BUILD-SNAPSHOT`
* Moved `AmqpOutboundEndpointTests` assertions to `AssertJ` to avoid
conflicts with `master`
Fixes https://github.com/spring-projects/spring-integration/issues/2752
The logic in the `IntegrationRequestMappingHandlerMapping` fully depends
on the application context it has been registered with, therefore any
arbitrary `ContextRefreshedEvent` doesn't fit our requirements.
More over it may cause a problem with missed mappings when parent-child
configuration is used.
**Chery-pick to 5.1.x, 5.0.x & 4.3.x**
Fixes https://github.com/spring-projects/spring-integration/issues/2744
When we get scattering results, there is no reason to keep internal
headers any more.
* Fix `ScatterGatherHandler` to modify scattering result messages to
reinstate headers from original request message.
This way we are able to re-throw an exception from the gatherer to
the caller.
* Fix typos and language in Docs
* Do not modify files which already has an actual year in the Copyright
* Make it to be performed really before any compilation, there change
to `compileKotlin.dependsOn updateCopyrights`
We really don't need to parse `inputs.files` for wrong XSD configuration.
This is already a responsibility of the task.
There is just enough to track changes in the XML configs and if they
happened only after that treat the task as out of date and parse configs
for wrong XSD configuration
To avoid extra manual task to check all the files for actual Copyright
header an `updateCopyrights` is introduced to be performed before
`processResources` and check modified classes via `Git status` command
by the `grgit` plugin.
The `updateCopyrights` task is enabled only locally: when it's not on
Travis or Bamboo - no reason to infer code base when it is not going
to be committed.
* Introduce `JavaUtils` for chaining properties setting
* Fix method complexity in the `ServerWebSocketContainer` using newly
introduced `JavaUtils`
* Make `JavaUtils` as `final`
Fixes https://github.com/spring-projects/spring-integration/issues/2731
When we have a nested gateway configuration, we are losing the context
of the current request message in case of errors and the downstream
`MessagingException` is just re-thrown as is, without the proper
`failedMessage` and its processed `errorChannel` header.
* Check for exception type and for the `errorChannel` header in the
current `requestMessage` before re-throwing as a new
`MessageHandlingException` in the `MessagingGatewaySupport.sendAndReceive()`
* Extract `.gateway()` tests into the separate `GatewayDslTests` class
* GH-2727: Ensure JDBC queries are logged
Fixes: https://github.com/spring-projects/spring-integration/issues/2727
The `JdbcTemplate` logs a message for the sql to execute when it is
supplied by the `QueryProvider`.
* Refactor `JdbcPollingChannelAdapter` to use new introduced internal
`PreparedStatementCreatorWithMaxRows` with the `QueryProvider`
* Refactor `JdbcMessageHandler` to instantiate a `generatedKeysStatementCreator`
based on the `PreparedStatementCreatorFactory`
* Verify in the `JdbcOutboundGatewayParserTests` that both fixes logs
sql queries properly
* * Implement all the delegate interfaces for the `PreparedStatementCreatorWithMaxRows`
* Add default expressions for ExpEvalReqHAdvice
https://stackoverflow.com/questions/54546728/how-to-handle-ftpoutboundadapter-connection-exception-in-spring-integration-flow
When channels are configured for the `ExpressionEvaluatingRequestHandlerAdvice`,
but no expressions, the logic is not performed.
In other words: we can evaluate expressions, when no channels,
but we don't send messages to channels when no expressions.
* Provide default expressions to be evaluated to `payload`, when only
channels are provided.
* * Remove asserts for expression setters
Fixes https://github.com/spring-projects/spring-integration/issues/2733
`AbstractMessageChannel` exception meters caused a memory leak because they
are stored in a `Set` for destruction purposes but did not implement
`hashCode` and `equals`.
Add `hashCode()` and `equals()` to all meter facades, delegating to the
underlying Micrometer objects.
JIRA: https://jira.spring.io/browse/INT-4386
* Expose `java.time` in the `IntegrationEvaluationContextFactoryBean`
ot simply a `T()` SpEL operator
* Add `Instant` result evaluation to the `delayExpression`
* Make IOS.setTaskScheduler() as public
* Make `IntegrationObjectSupport.setTaskScheduler()` as `public` and
remove all the overrides for visibility
* Fix Sonar smells for all the affected classes
* * Fix `throws Exception` for affected classes to avoid compilation errors
* * Fix "merely rethrow" smell
* Revert `throws Exception` for `AbstractEndpoint.destroy()`
* * Catch a couple exceptions from `destroy()`
Fixesspring-projects/spring-integration#2723
Not all XML components support all the configuration properties.
For example Saxon HE doesn't support `XMLConstants.ACCESS_EXTERNAL_DTD`
and end up with an exception like:
`IllegalArgumentException: Unknown configuration property http://javax.xml.XMLConstants/property/accessExternalDTD`
* Change `XsltPayloadTransformer` to re-use `TransformerFactoryUtils`
from spring-ws as a centralized source of `TransformerFactory`
configuration.
* Wrap `XMLConstants.ACCESS_EXTERNAL_STYLESHEET` to the `try..catch`
and log INFO about not supported property
**Cherry-pick to 5.0.x & 4.3.x**
* Fix mail lock race condition & Sonar smells
https://build.spring.io/browse/INT-MASTERSPRING40-599/
* The `folderReadLock` might not be re-locked when `openFolder()`
throws an exception
* Fix all the Sonar smells for mail module
* Optimize all the dynamic `Assert` messages to `Supplier`
* Refactor `MailReceiverFactoryBean` to be based on the `AbstractFactoryBean`
* * Fix new reported Sonar smells
* * Log error during cancel idle state in the `ImapMailReceiver`
* Remove commented code in the `MailTransportUtils`
* Some file module Sonar fixes
* * Fixes after testing
* * Some further Sonar fixes for file module
* * Further Sonar fixes for file module
* * More Sonar fixes for file module
* * Fix `RemoteFileTemplate` issues
* * Fix new sonar smells after previous one
* * Review feedback
JIRA: https://jira.spring.io/browse/INT-2549
* Add `expectReply` property into the `OperationInvokingMessageHandler`
to align the one-way and request-reply behavior with all other similar
components in Spring Integration
* Ignore an operation invocation result in case of `expectReply == false`
and log warning
* Provide some refactoring into the `OperationInvokingMessageHandler`
to fix Sonar complains about complexity
**Cherry-pick to 5.0.x, 4.3.x**
According Sonar we can't just leave lock unlocked in th method, so
apply refactoring for the `AbstractMailReceiver.receive()` where we don't
have uncontrolled `lock()` in the separate method
Since an `IntegrationComponentSpec` is a `FactoryBean`, all it's target
callbacks and lifecycle is controlled over a `FactoryBean`.
* Add `SmartLifecycle` for the `IntegrationComponentSpec` to delegate
lifecycle hooks to the `target` if necessary
* Refactor `IntegrationComponentSpec` to be an `AbstractFactoryBean`
which is a central place for the `FactoryBean`, `InitializingBean` and
`DisposableBean` interfaces
**Cherry-pick to 5.0.x**
* * Fix new Sonar issue in the `AbstractMailReceiver`
* * Move `unlock()` to its own `finally`
* * Make `ImapMailReceiverTests.imapIdleServer` non-static to allow
recreate the mail server for each test method
https://build.spring.io/browse/INT-MASTERSPRING40-591/
* * Remove MongoDb download from Travis config
* * Fix Checkstyle violation
