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)
JIRA: https://jira.spring.io/browse/INT-4028
Previously the `ClientWebSocketContainer` after the connection failure couldn't be restored even after `stop()/start()`
because the `openConnectionException` property hasn't been clear on `stop()`
* Add `openConnectionException = null` to `stopInternal()` logic
* Also clear `openConnectionException` and `clientSession` on `start()`
* Plus add recovery (restart) logic into the `getSession()` if the `!clientSession.isOpen()`
**Cherry-pick to 4.2.x**
Fix race condition around `start/stop`
The new `start/stop` logic brakes the in-flight connection.
* Introduce one more `connecting` flag to indicate that we are in connecting process.
* Absorb the a new test for `ClientWebSocketContainer` with the existing one. Looks like there is some extra session close in between.
* Adjust timeouts in the `StompIntegrationTests` to 20 secs. Add `org.apache.catalina` category for tracing logs
JIRA; https://jira.spring.io/browse/INT-4024
When the `FailOverClientConnectionFactory` is used on top of a
`CachingClientConnectionFactory`, the underlying connection's listener
is changed to the new `CachedConnection` which in turn has its
listener set to the new `FailoverTcpConnection`.
Since the caching connection factory implies single-use (so the connection
is "closed" - returned to the cache), the `FOCCF`
is also forced to have single-use = true - hence the new ultimate listener.
The `TcpNetConnection` obtained its listener (`getListner()`) in the outer
block of its read loop and hence did not detect the listener change.
This caused the old listener (cached connection) to be invoked and when
the result was ultimately passed back to the `TcpOutboundGateway`, the
connection id did not match and the reply eventually timed out.
Change the `TcpNetConnection` to call `getListener()` for every message.
This was already the case in `TcpNioConnection`.
https://build.spring.io/browse/INT-B43-199/
The `circuitBreakerTests()` relied on the enough short `Thread.sleep(100)`,
which may not be enough in the heavy-load environment like CI Server.
Therefor the time in between thread switching really can be much bigger than expected.
* Fix the test via timeout "emulation" using reflection to set the `lastFailure` somewhere in the past
to overcome `RequestHandlerCircuitBreakerAdvice.halfOpenAfter` barrier
JIRA: https://jira.spring.io/browse/INT-4023
There is no guaranty that following `System.currentTimeMillis()` return the same value.
That is how the `assertEquals()` test for `created` and `modified` value may fail sporadically.
* Fix `MongoDbMessageStore` and `ConfigurableMongoDbMessageStore` do not use a new `System.currentTimeMillis()`
in case of `group create`
**Cherry-pick to 4.2.x**
* To avoid a compiling noise like:
```
warning: No processor claimed any of these annotations: org.springframework.integration.support.management.IntegrationManagedResource,org.springframework.jmx.export.annotation.ManagedResource
```
add `-processing` option to the `compileTestJava.options.compilerArgs`
* Remove such an option from the `JPA` module as redundant
* Fix typos in the `spring-integration-file-4.3.xsd`
JIRA: https://jira.spring.io/browse/INT-4021
Previously the `SimpleMessageStore` unconditionally followed with the super class options
and provided the `lazy-load` functionality by default.
* Since `persistent` and `lazy-load` logic does not make sense for the `in-memory` store, disable it in the `SimpleMessageStore`
* Fir `AggregatorTests` for better coverage.
* NOTE: The same message can't be persisted in the Persistent `MessageStore`. The store key is fully based on the `messageId`.
And also we provide the header which indicates that the messages has been stored before. See `JdbcMessageStore.addMessage()` for example:
```
if (message.getHeaders().containsKey(SAVED_KEY)) {
Message<T> saved = (Message<T>) getMessage(message.getHeaders().getId());
if (saved != null) {
if (saved.equals(message)) {
return message;
} // We need to save it under its own id
}
}
```
* Fix (S)FTP Streaming tests to use `AbstractPersistentAcceptOnceFileListFilter` instead of raw `AcceptOnceFileListFilter`,
which relies on the object identity, but neither `FtpFile`, nor `ChannelSftp.LsEntry` provides good `equals()` and `hashCode()` implementations.
* Make `StompIntegrationTests` as `DirtiesContext.ClassMode.AFTER_EACH_TEST_METHOD` because the sporadic failure on the Travis around wrong value from the queue isn't clear (yet).
Looks like some interim event is generated by the Websocket Container on the Tomcat.
1. The fix for `SI-feed` module wasn't proper and we still see a `deprecation` warns during testing with Gradle.
* Move all deprecated `com.rometools.fetcher` imports directly to their classes declaration in the `FeedEntryMessageSource`.
That allows `@SuppressWarnings("deprecation")` to work properly
2. The latest nightly tests against IO demonstrate that upgrading to the `curator-3.1.0` has been hasty.
And it pulls as transitive `ZK-3.5.1-alpha`. The last one isn't appropriate for our stable IO dependencies.
But on the other hand the first one isn't compatible with `ZK-3.4.x`:
> The are currently two released versions of Curator, 2.x.x and 3.x.x:
> Curator 2.x.x - compatible with both ZooKeeper 3.4.x and ZooKeeper 3.5.x
> Curator 3.x.x - compatible only with ZooKeeper 3.5.x and includes support for new features such as dynamic reconfiguration, etc.
* The consolidate decision with Spring Cloud team to stay with the latest curator version which pull the latest stable ZK version.
Therefore downgrade to `curator-2.10.0`
* Additional decision is always to rely on the curator's transitive dependency for ZK and don't provide explicit to avoid versions incompatibility.
JIRA: https://jira.spring.io/browse/INT-4020
The fix for `named` global `wire-tap`s (INT-2230) didn't covered testing for `unnamed`.
Therefore the fix unconditionally didn't picked up the issue that we used a wrong `BeanDefinition` to determine the current `id`
* Fix `WireTapParser` to use `wireTapBeanName` from the `resolveId()` when the `GlobalChannelInterceptorParser` invokes it.
* Add tests to demonstrate the issue and confirm the fix
**Cherry-pick to 4.2.x**
JIRA: https://jira.spring.io/browse/INT-4006
* Upgrade to `rometools-1.6.0`
* Fix `FeedFetcher` typo in the XSD
* Since the `FeedFetcher` (and the whole `feed-fetcher` jar) is deprecated, provide an appropriate `@SupressWarning("deprecation")`
* Deprecate `FileUrlFeedFetcher` as well
JIRA: https://jira.spring.io/browse/INT-4005
* The `<int:queue>` lets declare the `capacity` attribute together
with either `message-store` or `ref` attributes, which it is not
correct
* The `<int:queue>` lets declare the `capacity` attribute together
with either `message-store` or `ref` attributes, which it is not
correct
* The `priority-queue` lets declare the `capacity` attribute
together with the `message-store` attribute, which it is not
correct
* Reference documentation fixed for `channel.adoc` and `jdbc.adoc`,
doing mention about these restrictions
* Minor changes about conventions and formats applied.
Code polishing
JIRA: https://jira.spring.io/browse/INT-4019
* Add `org.gradle.daemon=true` to `gradle.properties`
* Add `--no-daemon` to CI plans, such as `master` and `nightly`
* Adjust `.travis.yml` to disable `gradlew assamble` task and allow artifacts caching
Add `script` to `.travis.yml` config
Since we have sometimes the problem with cached dependencies and the Travis report doesn't reflect the reality properly,
add `--refresh-dependencies` to avoid such a caching bottleneck
Also add `--parallel` for experiment to see if a new Gradle and Travis can overcome that now
No `--parallel`
Doesn't work forTravis. It indicates the maximum load for CPU as a critical error and interrupts the spawned Gradle Threads
Add `--no-daemon`
This option does not make sense for Travis. It starts a new environment for each build.
Meanwhile looks like `caching` and `--refresh-dependencies` do their premise
JIRA: https://jira.spring.io/browse/INT-4015https://jira.spring.io/browse/INT-3854
Initial commit.
Reworked to emit an input stream and use the file splitter.
Add StreamTransformer.
Add CLOSABLE_RESOURCE header so we can close the session automatically.
Implement INT-3854, FTP, SFTP
(S)FTP Namespace Changes
Docs - also fixes a PDF overflow
Polishing - PR Comments
checkstyle fixes
Polishing - Add Namespace for StreamParser
Polishing - PR Comments
JIRA: https://jira.spring.io/browse/INT-4011
* The `jdbc.adoc` has an incorrect reference in a snippet code about
*Priority Channel*. The correct attribute value must be `channelStore`
JIRA: https://jira.spring.io/browse/INT-4003
* The `channel.adoc` has a wrong mention of `JdbcMessageStore`,
when the `JdbcChannelMessageStore` must be used
* Upgrade to SA and SF snapshots
* Address TODOs regarding those upgrades
* Resolve some other TODOs
* Replace `PropertyPlaceholderConfigurer` beans with the `<context:property-placeholder>`
* Upgrade to Spring Social Twitter 1.1.2 and resolve deprecations via mocks (https://github.com/spring-projects/spring-social-twitter/issues/91)
* Upgrade to Curator `3.1.0` and resolve deprecation in the `ZookeeperMetadataStore`
