JIRA: https://jira.spring.io/browse/INTEXT-106
* Upgrade to SI 4.0 and other libs
* Upgrade to Gradle 1.12
* Polisihng for `build.gradle`
* Fix compile warnings
* Use new `joinGroup(SocketAddress, NetworkInterface)` API
* Resolve `NetworkInterface` in UDP components as
`getByInetAddress(InetAddress.getByName(localAddress))`
* join group as `socket.joinGroup(new InetSocketAddress(this.group, 0), null);`
* Fix `SocketTestUtils.chooseANic()` to select a real `NetworkInterface`
bound to a real IP address
* Fix `MulticastRule` to populate a `multicast.local.address` against a
host name for the network interface not an interface logical name
* Support Java 14
* Provide changes to avoid deprecated Java API
and have a compatibility back to Java 8
* Change affected test classes to JUnit 5 whenever it is possible
* Ignore/Disable some TCP/IP tests which don't pass on Java 14
* Fix (some) TCP tests on JRE 14
* Fix SSL Handshake test - client side handshake is successful with java 14
- change the badClient cert to a badServer cert to force an error on the client side
Co-authored-by: artembilan <raven666>
Co-authored-by: Gary Russell <grussell@pivotal.io>
Fixes https://github.com/spring-projects/spring-integration/issues/3307
The `DefaultLockRepository.acquire()` is transactional method and
can fail with the `TransactionTimedOutException`.
When we call `JdbcLock.lock()`, we expect an attempt until we really obtain a lock.
* Treat a `TransactionTimedOutException` as a `TransientDataAccessException` and
therefore retry a locking attempt logic
**Cherry-pick to 5.3.x, 5.2.x & 4.3.x**
Resolves https://github.com/spring-projects/spring-integration/issues/3299
Connect before creating the `TcpNioConnection` object and publishing the
`TcpConnectionOpenEvent`.
This was a regression caused by supporting connect timout; which moved
the connect to after the object was created and event published, causing
the `connectionId` to start with `unknown`.
**cherry-pick to 5.3.x, 5.2.x**
* GH-3283: HTTP Inbound handle SpEL errors
Fixes https://github.com/spring-projects/spring-integration/issues/3283
* Process all the request message preparation exceptions
in the provided error channel to let target application
to make a decision about an appropriate HTTP status instead of
default 500 Server Error
* * Rephrase `ResponseStatusException` doc in the http.adoc
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
* GH-3280: NullChannel as reply for void gateways
Fixes https://github.com/spring-projects/spring-integration/issues/3280
To properly support a one-way gateway (`void` return type), it is
better to ignore any possible replies from downstream instead of
unexpected `no output-channel or replyChannel header available`
error
* Populate a `nullChannel` into a `replyChannel` header
for `void` gateway methods when `replyChannel` is not set explicitly
* Remove redundant `GatewayProxyFactoryBean.PARSER` in favor of
similar `EXPRESSION_PARSER` in the super class
* Test and document the feature
* * Fix language in the `whats-new.adoc`
Co-authored-by: Gary Russell <grussell@vmware.com>
* * Fix language in gateway.adoc
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
Fixes https://github.com/spring-projects/spring-integration/issues/3288
* For better end-user experience with Kotlin DSL and get a gain from
existing `Transformer` implementations add a `transform(Transformer)`
EI-method into the `KotlinIntegrationFlowDefinition`
* Also add `filter(MessageSelector)` for any out-of-the-box `MessageSelector`
**Cherry-pick to 5.3.x**
* GH-3282: Fix JdbcMetadataStore for DuplicateKeyEx
Fixes: https://github.com/spring-projects/spring-integration/issues/3282
The `INSERT INTO ... SELECT ... FROM ... HAVING` may fail with
`DuplicateKeyException` in between transactions.
* Catch `DuplicateKeyException` from in the `tryToPutIfAbsent()`
and return `0` as a fact of not inserted to let other logic to work
as expected.
There is no test coverage for this since it is almost impossible to
reproduce such a race condition on DB
**Cherry-pick to 5.3.x & 5.2.x**
* * Remove misleading message in the comment sentence
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`
1. Add proper terminating tags for `request-handler-advice-chain`.
2. Replace `int:request-handler-advice-chain` with `int-http:request-handler-advice-chain` when used inside of an `int-http:outbound-gateway`.
3. Replace `<bean ref="*" />` with `<ref bean="*" />`
4. Replace `</int:int:service-activator>` with `</int:service-activator>`
Fixes https://github.com/spring-projects/spring-integration/issues/3271
When exception happens at `.withPayload(session.readRaw(remotePath))`
in the `AbstractRemoteFileStreamingMessageSource` we don't close session.
The resource leaking happens in the caching session factory
* Add `session.close();` into the `catch (IOException e) {`
in the `AbstractRemoteFileStreamingMessageSource.doReceive()`
to clean up resources properly
**Cherry-pick to 5.2.x, 5.1.x & 4.3.x**
