https://build.spring.io/browse/INT-FATS5IC-457
The H2 `1.4.197` has fixed some issues
(in particular https://github.com/h2database/h2database/issues/178)
and introduced some breaking changes for us, although they are
reasonably good.
* Fix `JdbcOutboundGatewayParserTests` to use correct identifiers
for returned generated keys instead of previously used `SCOPE_IDENTITY()`
**Cherry-pick to 5.0.x and 4.3.x**
(cherry picked from commit 7b86ca7)
# Conflicts:
# build.gradle
https://build.spring.io/browse/INT-AT42SIO-820/
The test configs use `fixed-rate="100"`.
This way when Inbound Channel Adapter is declared earlier in the
config than `<jdbc:embedded-database>`, there is a chance that we start
to poll DB before it is really initialized.
* Reorder config so embedded DB is initialized before an
Inbound Channel Adapter
**Cherry-pick to 5.0.x, 4.3.x and 4.2.x**
(cherry picked from commit da6f47c)
# Conflicts:
# spring-integration-jdbc/src/test/java/org/springframework/integration/jdbc/config/pollingWithSelectParameterSourceJdbcInboundChannelAdapterTest.xml
JIRA: https://jira.spring.io/browse/INT-4441
Possible concurrent updates to `AbstractCorrelatingMessageHandler.groupIds` and
`expireGroupScheduledFutures`.
(cherry picked from commit f9d5198)
# Conflicts:
# spring-integration-core/src/main/java/org/springframework/integration/aggregator/AbstractCorrelatingMessageHandler.java
For better traceability for errors during lock acquiring add DEBUG
logging message in the `catch` block before returning back to the main
loop for the next acquiring attempt
**Cherry-pick to 5.0.x and 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4430
When Iterator-based `FileSplitter` splits the file, and an exception
throws in downstream flow (in the same thread), the exception propagates
to the caller leaving underlying file reader opened.
This commit changes `AbstractMessageSplitter` the way, that,
when any exception happens, if Iterator implements `java.io.Closeable`,
its `close()` method will be called before propagating exception.
Also `FileSplitter`'s underlying iterator implements `Closeable` now.
* Make `CloseableIterator` to follow `Closeable` contract.
Now `CloseableIterator.close()` declares `IOException` and can be used
as base interface for `FunctionIterator`.
* Adjust tests.
Adjust tests to reflect the fact that we call `close()` on the reader
one more time in the end of iterator.
**Cherry-pick to 5.0.x and 4.3.x**
(cherry picked from commit 7f25cba)
# Conflicts:
# spring-integration-core/src/main/java/org/springframework/integration/splitter/AbstractMessageSplitter.java
# spring-integration-core/src/main/java/org/springframework/integration/util/FunctionIterator.java
# spring-integration-file/src/main/java/org/springframework/integration/file/splitter/FileSplitter.java
# spring-integration-file/src/test/java/org/springframework/integration/file/remote/StreamingInboundTests.java
# spring-integration-file/src/test/java/org/springframework/integration/file/splitter/FileSplitterTests.java
https://build.spring.io/browse/INT-MJATS41-1279
Looks like there is a race condition when our polling rate around
data base is too fast and we have access to the DB files even during
application context close.
* Stop polling channel adapter in the tests explicitly after test methods
* Increase some tests performance decreasing timeouts to wait
* Increase timeouts and performance in the `StreamTransformerParserTests`
# Conflicts:
# build.gradle
# spring-integration-jdbc/src/test/java/org/springframework/integration/jdbc/JdbcMessageStoreChannelIntegrationTests-context.xml
# spring-integration-jdbc/src/test/java/org/springframework/integration/jdbc/JdbcMessageStoreChannelIntegrationTests.java
# spring-integration-jdbc/src/test/java/org/springframework/integration/jdbc/JdbcMessageStoreChannelOnePollerIntegrationTests-context.xml
# spring-integration-jdbc/src/test/java/org/springframework/integration/jdbc/JdbcMessageStoreChannelOnePollerIntegrationTests.java
# spring-integration-stomp/src/test/java/org/springframework/integration/stomp/client/StompServerIntegrationTests.java
Cherry-picked from cb0d43db6b
JIRA: https://jira.spring.io/browse/INT-4402
Make `GlobalChannelInterceptorProcessor` as a `BeanPostProcessor`,
so it can apply global `ChannelInterceptor`s to any initialized channel
beans, even those created at runtime, like in case of dynamic flows with
Java DSL
**Cherry-pick to 4.3.x**
* Add `postProcessDynamicBeans` global property with `false` by default
* Rely on the `postProcessDynamicBeans` property in the
`GlobalChannelInterceptorProcessor.postProcessAfterInitialization()`
* Add `postProcessDynamicBeans=true` to the
`GlobalChannelInterceptorTests-context.xml` to be sure in the test-case
that option works
* Document the option and effect from the global channel interceptors
JIRA: https://jira.spring.io/browse/INT-4396
When target distributed `Lock` implementation throws an exception, e.g.
in case of no connection to the service, the `LockRegistryLeaderInitiator`
exists the loop and can come back to the elections only after restart
* Catch all the exception on `this.lock.tryLock()` and resubmit
`LeaderSelector` for a new locking cycle if
`LockRegistryLeaderInitiator.isRunning()` and `InterruptedException`
* Remove diagnostics from the `JdbcLockRegistryLeaderInitiatorTests`
since this fix confirms that we just didn't have a reconnect logic before
when this test failed sporadically
**Cherry-pick to 4.3.x**
# Conflicts:
# spring-integration-core/src/main/java/org/springframework/integration/support/leader/LockRegistryLeaderInitiator.java
# spring-integration-jdbc/src/test/java/org/springframework/integration/jdbc/leader/JdbcLockRegistryLeaderInitiatorTests.java
JIRA: https://jira.spring.io/browse/INT-4394
Looks like Jackson has became much smarter and now it stores
the target type for the object, not returned interface.
We can't use Jackson annotations on the Framework classes and
we can't restrict the `messagingAwareMapper()` `ObjectMapper` just
to use fields for all the object passed through it.
As a compromise solution we shouldn't use
`Collections.unmodifiableList()` in the getter.
The copy of the internal collection is pretty enough to protect
our object from mutation.
**Cherry-pick to 4.3.x (excluding `build.gradle` change)**
# Conflicts:
# build.gradle
https://build.spring.io/browse/INT-FATS5IC-400
When we run several concurrent builds (e.g. CI) and use the same shared
Redis server we may end up with the case when one process reads data
populated by another because we use the same key (groupId in our case)
* Fix `RedisMessageGroupStoreTests` to use `UUID.randomUUID()`
for the `groupId`
**Cherry-pick to 4.3.x**
# Conflicts:
# spring-integration-redis/src/test/java/org/springframework/integration/redis/store/RedisMessageGroupStoreTests.java
https://build.spring.io/browse/INT-MJATS41-1242
When different `DefaultLockRepository` instances use the same client id,
there is a possibility that they will update the same row in the table.
This way we have a chance that not only one obtains a lock and try to
add a value to the collection.
* Remove the test-case for the same client id as non-stable and even
dangerous by the the distributed lock purpose
* Use `tryLock(Long.MAX_VALUE)` to really ensure the wait behavior
during the concurrent loop
* Use `20` for thread pool to align with the tasks amount
**Cherry-picked to 4.3.x**
# Conflicts:
# spring-integration-jdbc/src/test/java/org/springframework/integration/jdbc/lock/JdbcLockRegistryDifferentClientTests.java
https://build.spring.io/browse/INT-SI43X-230
Looks like Ruby engine takes some time to start and
`Jsr223InboundChannelAdapterTests` is slow as 3 seconds locally as well
* Change the script to JavaScript and now we have 200 millis
**Cherry-pick to 4.3.x**
(cherry picked from commit c48a239)
JIRA: https://jira.spring.io/browse/INT-4366
The `MulticastSendingMessageHandler.getSocket()` doesn't guard around
`this.multicastSocket` property causing `NPE` and other inconsistency
in the multi-threaded environment
* Make the whole `MulticastSendingMessageHandler.getSocket()` as
`synchronized` like it is with the super method
* Reuse `closeSocketIfNeeded()` in the
`UnicastSendingMessageHandler.handleMessageInternal()`
* Fix type in the `UnicastSendingMessageHandler` logging message
* Fix `UdpChannelAdapterTests` for missed `BeanFactory` for the SpEL
and also `MulticastSendingMessageHandler.stop()` in one missed places
**Cherry-pick to 4.3.x**
# Conflicts:
# spring-integration-ip/src/main/java/org/springframework/integration/ip/udp/UnicastSendingMessageHandler.java
https://build.spring.io/browse/INT-MASTER-901
The `JdbcLockRegistryDifferentClientTests.testOnlyOneLock()` relies
on the `ArrayList.isEmpty()` state to proceed with the logic.
But since the `ArrayList.size` property is not `volatile`, there is no
guarantee for the proper state in the multi-threaded environment like
we have in this test-case.
* Replace `ArrayList` in the test with the `LinkedBlockingQueue` which
already rely on the `AtomicInteger` for the `size` property
* Fix `JdbcLockRegistry` tests to shutdown used `ExecutorService` s
to ensure set free threads after test suite execution.
**Cherry-pick to 4.3.x**
# Conflicts:
# spring-integration-jdbc/src/test/java/org/springframework/integration/jdbc/lock/JdbcLockRegistryDifferentClientTests.java
# spring-integration-jdbc/src/test/java/org/springframework/integration/jdbc/lock/JdbcLockRegistryTests.java
JIRA: https://jira.spring.io/browse/INT-4382
There is a deadlock in the FMWH due to lock ordering.
Writes try to lock the handler monitor while holding the file lock.
The `Flusher` tries to lock the file lock while holding th handler monitor.
- Change the `Flusher`, `stop` and `flushIfNeeded` methods to not call close
on the file state while holding the handler monitor.
__cherry pick to 4.3.x__ (fix <> for Java 6)
Polishing - PR Comments
* Optimize `flushIfNeeded(FlushPredicate)` to delegate only to the
`flushIfNeeded(MessageFlushPredicate, Message<?>)`
# Conflicts:
# spring-integration-file/src/main/java/org/springframework/integration/file/FileWritingMessageHandler.java
JIRA: https://jira.spring.io/browse/INT-4366
Fix race condition in the `MulticastSendingMessageHandler` around
`multicastSocket` and super `socket` properties.
* Synchronize around `this` and check for the `multicastSocket == null`.
This let the `MulticastSendingMessageHandler` to fully configure and
prepare the socket for use.
* Remove `socket.setInterface(whichNic)` since it is populated by the
`InetSocketAddress` ctor before
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4379
- shutdown the container when the gateway is stopped
Also, improve test suite
- at the end of the tests, hundreds of threads are running, some caused by the above
but others because `TaskExecutor`s are not shut down
- reduce the number of iterations in the JMS pipeline tests to speed things up
- change more tests to extend `ActiveMQMultiContextTests`, to keep a single broker up
__cherry-pick to 4.3.x__
# Conflicts:
# spring-integration-jms/src/main/java/org/springframework/integration/jms/JmsOutboundGateway.java
# spring-integration-jms/src/test/java/org/springframework/integration/jms/JmsOutboundGatewayTests.java
# spring-integration-jms/src/test/java/org/springframework/integration/jms/OutboundGatewayConnectionTests.java
# spring-integration-jms/src/test/java/org/springframework/integration/jms/OutboundGatewayFunctionTests.java
# spring-integration-jms/src/test/java/org/springframework/integration/jms/PollableJmsChannelTests.java
# spring-integration-jms/src/test/java/org/springframework/integration/jms/SubscribableJmsChannelTests.java
The `SpelPropertyAccessorRegistrar` ctor and
`add(PropertyAccessor... propertyAccessors)` method use wrong variable
to build a key for the provided `PropertyAccessor`.
Therefore during iteration the next `PropertyAccessor` overrides the
previous and we end up just only with one instance in the registry
* Extract `private static obtainAccessorKey()` method to build
decapitalized key for the `PropertyAccessor`
* Change the map store to the `LinkedHashMap` to keep order of the
provided `PropertyAccessor` s
* Modify `EnableIntegrationTests` to ensure that we support several
`PropertyAccessor` s and in the proper order
**Cherry-pick to 4.3.x**
Resolves: spring-projects/spring-integration#2275
* Remove the `MqttPahoMessageDrivenChannelAdapter` as a callback from
the `IMqttClient` during `stop()`
* Check the `isRunning()` from the `connectionLost` callback to avoid
unexpected `scheduleReconnect()` when we are not running
**Cherry-pick to 4.3.x**
Conflicts:
spring-integration-mqtt/src/test/java/org/springframework/integration/mqtt/MqttAdapterTests.java
Resolved.
The `StompSubProtocolHandler` explicitly sets `stompCommand` header
to the `MESSAGE` value ignoring any client inputs.
In this case the message is treated as from the server and ignored on
the STOMP Broker side from the client session.
* Introduce `ClientStompEncoder` for the client side to be injected
into the `StompSubProtocolHandler` for the proper client side messages
encoding/decoding.
Override `stompCommand` header to the `SEND` value if it is `MESSAGE`
before encoding to the `byte[]` to send to the session
JIRA: https://jira.spring.io/browse/INT-4360
**Cherry-pick to 4.3.x**
Fix WebSocket test to rely on the proper client config class
and don't pick up the server config unconditionally in the test context
Conflicts:
spring-integration-websocket/src/test/java/org/springframework/integration/websocket/client/StompIntegrationTests.java
Resolved.
https://build.spring.io/browse/INT-MJATS41-1150
When we add `addHandler()` to the `CompositeStompSessionHandler`,
there is no guarantee that we will have `session` atomically during
this method invocation or after it relying on the later call to the
`this.delegates`.
In other words the session may be populated in between and, therefore,
our `delegate` loses `afterConnected()` event.
We need to synchronize on the barrier and block the concurrent
`afterConnected()` or wait for it.
This way we atomically ensure that our `delegate` is added to the
existing `session` or will be performed afterwards in the `afterConnected()`
**Cherry-pick to 4.3.x**
(cherry picked from commit df10941)
JIRA: https://jira.spring.io/browse/INT-4345
Resolves https://github.com/spring-projects/spring-integration/issues/2238
The `DefaultHandshakeHandler` doesn't implement `SmartLifecycle`
(just `Lifecycle`) there it doesn't delegate its `start()` to the
`RequestUpgradeStrategy`, e.g. `JettyRequestUpgradeStrategy`.
On the other hand `DefaultHandshakeHandler` can be started as a dependant
`Lifecycle` from some other `SmartLifecycle`, like it happens with the
`WebSocketHandlerMapping`
* Implement `SmartLifecycle` for the `ServerWebSocketContainer` and
delegate its lifecycle to the provided `HandshakeHandler`
* Fix `WebSocketInboundChannelAdapter` to properly implement `doStop()`
with the propagation to the provided `webSocketContainer`
* Fix deprecation warning in the `StompMessageHandlerWebSocketIntegrationTests`
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4344
The `FtpOutboundGateway` provides ctors without expression for remote path.
In this case it is treated as a `working directory` but only for the
`LS`, `NLST`, `PUT` and `MPUT` commands.
* Add assertion in the `AbstractRemoteFileOutboundGateway` to discard
configuration for all other commands when `expression` is `null`
**Cherry-pick to 4.3.x**
Conflicts:
spring-integration-file/src/main/java/org/springframework/integration/file/remote/gateway/AbstractRemoteFileOutboundGateway.java
Resolved.
JIRA: https://jira.spring.io/browse/INT-4354
It's hard to test different ClassLoader in unit tests, so the fix
comes without them
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4356
**Cherry-pick to 4.3.x**
Address PR comments:
* Remove unused variable in the test case
* Add string-based SpEL setters to the `AbstractInboundFileSynchronizer`
* Fix `@since` in the `FileTransferringMessageHandler` to the proper version
Conflicts:
spring-integration-file/src/main/java/org/springframework/integration/file/remote/handler/FileTransferringMessageHandler.java
spring-integration-file/src/main/java/org/springframework/integration/file/remote/synchronizer/AbstractInboundFileSynchronizer.java
Resolved.
Fixes: spring-projects/spring-integration#2261
* Fix `ScatterGatherHandler.stop()` to call `GatherEndpoint.stop()` instead of `start()`
Adding unit test as per artembilan's suggestion
Replacing asterisk import with specific namespaces
Fixing formatting/codestyle errors shown by travis
Creating separate bean for new unit test
* Some simple polishing
* Merge the assertions for the fix into an existing test
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4353
Updated based on code review
* Polishing according PR comments
**Cherry-pick to 4.3.x**
# Conflicts:
# src/reference/asciidoc/jdbc.adoc
