See https://build.spring.io/browse/INT-AT42SIO-199/
In some places we start `Cache` but doesn't close/destroy it in the end.
That sometimes causes conflicts with the already started GemFire from other tests or wrong state around `BeanFactoryLocator`
* Ensure `Cache` destroy in the end of each test
* In addition destroy `Region` as well to avoid unexpected race conditions, too
* Plus optimize some tests to start `Cache` and `Region` only once per test class, not for each test method
From here I can say that it even would be better to start `Cache`, and therefore whole GemFire, only once per entire Gemfire module test suite.
But that is fully different story.
Remove `forkEvery` from Gemfire module
Allow get a performance improvement for the build.
The `gradlew clean :spring-integration-gemfire:testAll` with existing state is like:
```
Total time: 3 mins 41.375 secs
```
With this fix and without `forkEvery`:
```
Total time: 1 mins 42.699 secs
```
So, 2 min saved time!
Plus fix timeouts in the `PayloadSerializingTransformerParserTests`
JIRA: https://jira.spring.io/browse/INT-1463
An existing `QueueChannel#getRemainingCapacity()` is based on the `BlockingQueue#getRemainingCapacity()` which is always `Integer.MAX_VALUE`
and doesn't reflect reality for provided `capacity`
* Fix `PriorityChannel` to return `upperBound.availablePermits()` for `getRemainingCapacity()`
* Add test for `PriorityChannel` on the matter
* Also increase `reply-timeout` for `<int-redis:queue-outbound-gateway>` in `RedisQueueGatewayIntegrationTests-context.xml` from 1 sec to 10 secs
JIRA: https://jira.spring.io/browse/INT-4061
The `FTPClient.changeWorkingDirectory()` can be performed only after proper connection to the target FTP server
* Fix `ftp.adoc` to mention proper `postProcessClientBeforeConnect()` callback.
* Make other minor polishing for the `ftp.adoc`
JIRA: https://jira.spring.io/browse/INT-4058
If you hold the lock, you are the leader. This simple idea gets you
a long way if there is no "native" leader initiator. E.g. you
can use this with a RDBMS with JdbcLockRegistry.
Add some docs on leader election under "endpoints"
Make thread name for leader initiator unique
In case there are multiple instances in the same context we would
like to be able to spot them in the logs.
INT-4058: Polishing
* Code refactoring in the `LockRegistryLeaderInitiator`: SI use 120 line length
* Add `Assert.notNull()` for required properties
* Add `this.lock.unlock()` and `Thread.sleep(LockRegistryLeaderInitiator.this.busyWaitMillis)` into the `catch` block to let distributed elections to work.
Otherwise there is a big chance that we will acquire the lock and become a leader again just after `yield()`
* Change `LockContext.toString()` to use simple `String` concatenation which is optimized by compiler to the `StringBuilder`.
That let to have some better micro-performance compared with with extra `Formatter` object in case of `String.format()`
* Add `JdbcLockRegistryLeaderInitiatorTests`
* Fix `yield()` logic based on the `Future.cancel(true)`.
Since one `FutureTask.cancel(true)` makes it as `INTERRUPTED` any subsequent `yield()` does not make any effect, therefore our infinite selector loop isn't interrupted one more time.
* Reschedule the `LeaderSelector` in the `yield()` after cancel(true).
* Rework `catch` in the selector loop just to the `InterruptedException` and `return null;` to stop looping and let reschedule the selector.
* Add one more `onRevoked` logic into the `final` of the selector loop to notify that we have lost leadership during `stop()`
* Improve `JdbcLockRegistryLeaderInitiatorTests` to ensure that several `yield()` on the same initiator work well.
* Add `What's New` note.
JIRA: https://jira.spring.io/browse/INT-4054
Fixes GH-1833 (https://github.com/spring-projects/spring-integration/issues/1833)
The `DefaultCandidate` pulled requirement for the `slf4j` dependency via its `Logger` and `LoggerFactory` usage.
* Change `slf4j` to the standard Commons Logging
* Exclude `slf4j` transitive dependencies from `optional` direct dependencies like `reactor` and `json-path`
* Since they are `optional` it is safe to exclude their transitives to force our source code to be free from unexpected dependencies.
Anyway they don't appear in the target application as a SI transitives and end-user is forced to pull them manually to switch on the desired features.
If there is need in the `slf4j` for target application, it must be pulled manually as well.
**Cherry-pick to 4.2.x**
JIRA: https://jira.spring.io/browse/INT-4048
The semantics of the locks are the same as for the default lock
registry (they have to be unlocked by the same thread that
locked them).
Updates from feedback
Add interface for JdbcClient so transactions can bind to proxy
Fix typo in exception message
Fix drop script
JdbcClient -> LockRepository
Make lock() contract more like native Lock
Make lockInterruptibly throw InterruptedException more
Delete all expired locks, not just the ones that we own
INT-4048: Polishing
* `DefaultLockRepository`: replace `prefix` only once in the `afterPropertiesSet()`
* Add JavaDocs to the `DefaultLockRepository`
* `JdbcLockRegistry`: add `Thread.sleep(100)` to lock loops do not request DB so often like in case of clean `while(true)`
* `JdbcLockRegistry`: implement more robust `tryLock(long time, TimeUnit unit)`. The logic mostly copied from `RedisLockRegistry`
* Add `testExclusiveAccess()` to be sure that JDBC locks have exclusive access to the data sequence
Document `JdbcLockRegistry`
Upgrade to SF-4.3 GA
JIRA: https://jira.spring.io/browse/INT-4053
The recent changes to the `FileSplitter` introduced (by IDE autocompletion mistake) hidden dependency of Reactor using its `Assert` class instead of Spring's one
**Cherry-pick to 4.2.x**
JIRA: https://jira.spring.io/browse/INT-4051
Previously we can process `@Publisher` annotations only with the `<int:annotation-config>` or with an explicit `@EnablePublisher("")`
* Fix `PublisherRegistrar` to relax from the fact if we have `@EnablePublisher` or not and register `PublisherAnnotationBeanPostProcessor` without `defaultChannelName`
JIRA: https://jira.spring.io/browse/INT-4046
Since not all FTP servers provide proper `STAT` command implementation,
plus the `NLIST` doesn't work properly for directories cases, introduce the `FtpRemoteFileTemplate.ExistsMode`
to let:
* to perform `STAT` by default (previous) behavior;
* to switch to `NLIST` for `FtpRemoteFileTemplate` internal use;
* perform the full `NLIST` and `FTPClient.changeWorkingDirectory()` algorithm if needed.
* Improve (S)Ftp components to use proper `RemoteFileTemplate` for internal instantiation
* Introduce `FtpMessageHandler` to wrap `FtpRemoteFileTemplate` with the proper `NLIST` `ExistsMode`
* Cover `NLIST` switching from the `FtpOutboundChannelAdapterParser` and `FtpOutboundGatewayParser`
* Document the `FtpRemoteFileTemplate.ExistsMode`
* Fix typo in the recently introduced `RemoteFileOperations.getSession()` method name
* Add JavaDoc to `Session.exists()`
* Add `NLIST` support for the `FtpSession.exists()` to meet the API requirements
**Cherry-pick to 4.2.x and 4.1.x**
Addressing PR comments
Doc Polishing
JIRA: https://jira.spring.io/browse/INT-4045
Handle the situation when the first element of a container type (or map)
is null; set the generic type of the container to `Object`.
Also, clarify how the compatibility between the transformer and Spring AMQP
message converter is achieved.
JIRA: https://jira.spring.io/browse/INT-4043
The `ExecutorChannel` overrides `onInit()` but fails to call the super
which is where the message converter for datatype conversion is set up.
Also, when Jackson is not on the class path and there are no converters in the
context, the default integration conversion service is not registered.
The `DefaultDatatypeChannelMessageConverter` overwites its default conversion
service with this bean, unconditionally - setting it to null in this case.
Check for a null conversion service before replacing the default.
* Polishing according PR comments
JIRA: https://jira.spring.io/browse/INT-4044
The wrong method `WebSocketStompClient.connect()` has been used before because of `Object` vararg.
* Fix to the proper method invocation
* Modify `StompInboundChannelAdapterWebSocketIntegrationTests` with `origin` handshake header to prove the fix
JIRA: https://jira.spring.io/browse/INT-4038
General format for node name: bean.method#n
The #n is needed to disambiguate methods with the same name.
Polishing according PR comments
* Fix generic type for `Collections.unmodifiableMap` usage
* Change the gateway method logic in the `IntegrationGraphServer` to include the method signature in the node name to distinguish them as unique
* Move `MutableMessageBuilderFactoryTests` into the separate nested `mutable` package since `@IntegrationComponentScan` sees a new `@MessagingGateway` in the `IntegrationGraphServerTests`.
See https://jira.spring.io/browse/INT-4040
* Document the `@MessagingGateway` representation in the `graph.adoc`
JIRA: https://jira.spring.io/browse/INT-3997
* Created the `H2ChannelMessageStoreQueryProvider` class for the
`ChannelMessageStoreQueryProvider` interface
* The `LongRunningIntegrationTest` class needs the
`RUN_LONG_INTEGRATION_TESTS` variable defined in the 'system'
and set in true. It to let work the test methods for the
`H2TxTimeoutMessageStoreTests` class
* Updated reference documentation about `ChannelMessageStoreQueryProvider`
* Polishing
The `RedisMessageGroupStoreTests.testMessageGroupUpdatedDateChangesWithEachAddedMessage()` can fail
sporadically because there is no guaranty the several calls to the `System.getCurrentTimeMillis()` return the same value.
* Fix `AbstractKeyValueMessageStore` to reuse `MessageGroup.timestamp` for the `lastModified` in case of a new group
https://build.spring.io/browse/INT-MJATS41-629
* Revert to SF and SA BUILD-SNAPSHOTs
* Upgrade to Spring Security 4.1
* Fix `RedisQueueMessageDrivenEndpointTests.testInt3442ProperlyStop()` for `atLeastOnce()` verification
because in between stop and the last `rightPush` there might be one more `pop` and push again because of `listening = false` state
* There is still sporadic `OutboundGatewayFunctionTests.testLazyContainerWithDest()`, so revise all the JMS tests for:
- proper `ApplicationContext.stop()` in the end of test
- `@DirtiesContext` if `SpringJUnit4ClassRunner` is in use
- `TaskScheduler.destroy()` if that
The JMS fix might relate to the https://jira.spring.io/browse/INT-4030, therefore consider this fix for cherry-picking into `4.2.x` (excluding `build.gradle` changes)
