Resolves https://github.com/spring-projects/spring-integration/issues/2777
If the filter supports it, defer filtering until the last possible moment.
Then, the worst case scenario after a catastrophic failure (e.g. power loss),
would be that at most one file will be incorrectly filtered on restart.
Polishing and add more tests.
Polishing Javadocs
More Polishing
Final polishing
More polishing.
Polishing and docPolishing and docs.
* Fix typos in Docs
* Defer Messaging annotations process
The `AbstractMethodAnnotationPostProcessor` and its implementations
have a `beanFactory.getBean()` call for the `@Bean` methods with
Messaging annotations.
This is done, actually, from the
`MessagingAnnotationPostProcessor.postProcessAfterInitialization()`
which might be still too early in some scenarios, like Spring Cloud Feign
with its child application contexts being initialized from the
`FeignClientFactoryBean`, causing a `BeanCurrentlyInCreationException`
See https://stackoverflow.com/questions/54887963/beancurrentlyincreationexception-when-using-spring-integration-with-spring-cloud
* Implement a `SmartInitializingSingleton` for the `MessagingAnnotationPostProcessor`
and gather `Runnable` wrappers for newly introduced `postProcessMethodAndRegisterEndpointIfAny()`
to be called later in the `afterSingletonsInstantiated()` when context is
still in the initialization phase.
All runtime-registered beans are going to be processed normally from the
regular `postProcessAfterInitialization()`
**Cherry-pick to 5.1.x**
* * Fix unused imports in the `MessagingAnnotationsWithBeanAnnotationTests`
* * Fix `IntegrationEndpointsInitializer` in the testing framework to handle
all the possible `AbstractEndpoint` beans registration.
See its JavaDocs for more info
* Fix `AbstractCorrelatingMessageHandlerParser` and
`AbstractConsumerEndpointParser` to use bean names for `outputChannel`
and `discardChannel` instead of bean references.
Since `MessagingAnnotationPostProcessor` now registers endpoints and
beans for channels much later, than parsers, we can't rely on bean
references any more there.
* Fixes for failing tests which expected `outputChannel/discardChannel`
bean references, when it is already just their names for late binding.
* Apply some code style polishing for the affected classes.
* Add `@Nullable` for `MessageSelector` parameter in the `QueueChannel.purge()`
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**
* Fix new Sonar smells
* Fix some old Sonar smells as well
* Fix Micrometer leaks in the `PollableChannel` when we register
meters, but don't remove them.
* * Fix NPE around `MetricsCaptor` in channels
* * Fix new smells according test report
* * Further Sonar smell fixes
* * More smell fixes for `MessagingMethodInvokerHelper`
* Remove `throws Exception` from `AbstractMessageHandler.destroy()`
* * Fix complexity in the `MessagingMethodInvokerHelper.processInvokeExceptionAndFallbackToExpressionIfAny()`
JIRA: https://jira.spring.io/browse/INT-4573
* Fix check order for headers first in the `resolveObjectName()` and
`resolveOperationName()`.
Then fallback to defaults configured on the `OperationInvokingMessageHandler`
* Remove also a deprecated API in the `OperationInvokingMessageHandler`
* Remove requirements for `object-name` and `operation-name` XML
attributes since those options can be provided in the request message
headers
* Fix `OperationInvokingChannelAdapterParserTests` for proper headers
resolution
* Mention `JmxHeaders.OBJECT_NAME` and `JmxHeaders.OPERATION_NAME`
headers in the `jmx.adoc`
JIRA: https://jira.spring.io/browse/INT-4559
* Return a single item from result only if
`maxRows == null || maxRows == 1`
* Remove deprecated `max-rows-per-poll` from the
`JdbcOutboundGateway.java` and its XSD and parsers
Fixes https://github.com/spring-projects/spring-integration/issues/2760
* The `assertThatExceptionOfType()` is more convenient,
than `assertThatThrownBy`, so, replace all the usages accordingly
* Fix JavaDoc typo in the `AbstractScriptExecutingMessageProcessor`
* Fix Sonar smells for `throws Exception` in `AbstractScriptExecutingMessageProcessor`
hierarchy and some code polishing for them
* GH-2749: Deprecate ChannelInterceptorAware
Fixes https://github.com/spring-projects/spring-integration/issues/2749
The `org.springframework.messaging.support.InterceptableChannel` provides
exact functionality as `ChannelInterceptorAware`
* Make `ChannelInterceptorAware extends InterceptableChannel`
* Suppress deprecation warning whenever we need to keep backward
compatibility
* Fix all other places to deal with `InterceptableChannel` already
* GH-2749: Deprecate ChannelInterceptorAware
Fixes https://github.com/spring-projects/spring-integration/issues/2749
The `org.springframework.messaging.support.InterceptableChannel` provides
exact functionality as `ChannelInterceptorAware`
* Make `ChannelInterceptorAware extends InterceptableChannel`
* Suppress deprecation warning whenever we need to keep backward
compatibility
* Fix all other places to deal with `InterceptableChannel` already
* * Fix `channel.adoc` for the current version
* 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
* Use `IntegrationUtils.wrapInHandlingExceptionIfNecessary()` whenever
it is possible to avoid double wrapping into the `MessageHandlingException`
* Some code polishing for affected classes `@Nullable`, streams, diamonds etc.
* The Gradle `checkTestConfigs` task deals only with resources,
so narrowing its `outputs` to the `build/resources`
* The Gradle `updateCopyrights` tasks deals only with compiled classes,
so narrowing its `outputs` to the `build/classes`
Mostly thanks to IDEA's plugin: https://plugins.jetbrains.com/plugin/10345-assertions2assertj
There is still a lot of work to do when complex and composite matchers are used.
* Add `awaitility` dependency and deprecate `EventuallyMatcher` in favor
of `awaitility`
* Remove Hamcrest from dependencies and disable JUnit & Hamcrest
static imports to encourage to use only AssertJ
* Migrate JUnit assumptions in rules to AssertJ's assumptions
* Deprecate some custom matchers in favor of existing in Hamcrest
after upgrading the last to version `2.1`
* Replace `ExpectedException` rules with `assertThatThrownBy()`
* Mention `MessagePredicate` in the `testing.adoc`
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**
* Upgrade to Gradle 5.2.1, SonarQube 2.7, asciidoctor 1.5.10,
Apache Sshd 2.2.0, AsertJ 3.12.0, Curator Framework 4.1.0, room Tool 1.12.0,
Checkstyle 8.17
* remove Eclipse Link support in JPA tests since it is not compatible
with Java 11
* Move 5.1 changes to the `changes-5.0-5.1.adoc`; start new "What's New"
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.
