* Move the plugin and its task into the root project configuration
* Add more image file extensions to exclude
* Fix `sftp.adoc` do not use HTTP url for the JSCH library project page;
use GitHub repo link instead
https://build.spring.io/browse/INT-MASTER-1568/
* Fix `whats-new.adoc` for broken link
* remove `logDocuments = true` from the `build.gradle`
* Change the Gradle task name in the `.travis.yml` for consistency
* Check external links have a description
* Use Groovy regex instead of Java
* Add source file name to exception message
* Add 'checkAsciiDocLinks' to Travis build
* 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
- to avoid having to load the whole document
- provide a link to the single page version for browser search
* Fix cross-document links.
Links need to be qualified with the containing file name for the
multi-page html doc.
* Add the support for a `Publisher`, `Resource` and `MultiValueMap`
into the `WebFluxRequestExecutingMessageHandler`
* Along side with the `WebFluxRequestExecutingMessageHandler.setPublisherElementType`
and `WebFluxRequestExecutingMessageHandler.setPublisherElementTypeExpression`,
add XSD support for the `publisher-element-type(-expression)`, which
is used for the element type when request body is a `Publisher`
* Polishing for `AbstractHttpRequestExecutingMessageHandler`
* Fix Sonar smells for affected classes
* Remove used imports
Doc polishing
* Add support for Kotlin JSR223 scripts
* Add required Kotlin dependencies into the `spring-integration-scripting`
module
* Introduce `KotlinScriptExecutor` to interact with the
`KotlinJsr223JvmLocalScriptEngineFactory` directly since there is no
`META-INF/services/javax.script.ScriptEngineFactory` file in the Kotlin
* Also set an `idea.use.native.fs.for.win` system property to `false` in
this class to disable check for native support on Windows.
(Might be removed in future Kotlin versions)
* Move `ScriptParser.getLanguageFromFileExtension()` logic into the
`ScriptExecutorFactory.deriveLanguageFromFileExtension()` since the same
one must be applied in the `DslScriptExecutingMessageProcessor`, too.
* Modify tests to reflect Kotlin support
* Fix some test scripts to their official extensions
* * Add JavaDocs
* Polishing according Sonar objections
* 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
* 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
See https://github.com/spring-projects/spring-integration/pull/2837
Give priority to accepting new connections over reading data from
existing connections.
Add a flag to allow users to revert to the previous behavior of
giving reads priority.
**cherry-pick to 5.1.x**
* 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`
* INT-3459: Log exceptions in case of failOver
JIRA: https://jira.spring.io/browse/INT-3459
When `UnicastingDispatcher` is configured with `failOver` (true by default),
it loses exceptions it caught with previous handler when the next one
processes message properly
* Add INFO logging for exceptions which are caught before going to fail
over to the next handler
* * Address PR comments
* * More PR comments
* Add a note about this logging into the `channel.adoc`
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
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`
* 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
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`
* 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
* 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
JIRA: https://jira.spring.io/browse/INT-2543
We may have a mail server host configured in the properties and the
target session will resolve it properly from provided `javaMailProperties`.
The same applies for `username`
* Do not require `host` and `username`, when `javaMailProperties` is
provided
* Add additional factory methods into the `Mail` factory for Java DSL
* Add Java DSL sample into the `mail.adoc`
