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`
JIRA: https://jira.spring.io/browse/INT-3994
If a header mapper is injected into the mail receiver, a mapped
message is result instead of a message with the raw `MimeMessage`.
`MimeMessage` properties are mapped as discrete headers; in addition
the raw email headers are provided as a multivalue map in the headers.
Handle Multipart
Since a Multipart content has a reference to the original MimeMessage,
convert to a simple byte[] by default.
Add an option in case the user wants to map the message but still
interpret the Multipart intact.
Namespace and Docs
Polishing
Polishing - PR Comments
JIRA: https://jira.spring.io/browse/INT-3991
* Add `IntegrationGraphController` `@RestController` over `IntegrationGraphServer` bean
* Add `@EnableIntegrationGraphController` and `<int-http:graph-controller>` to register
`IntegrationGraphController` if the `DispatcherServlet` is in classpath.
* Also register the `IntegrationGraphServer` bean from the same place, if that isn't presented in the application context yet.
* Allow to configure the "root" `path` for the `IntegrationGraphController` as a placeholder value via
`spring.integration.graph.controller.request.mapping.path` property
* Add tests for both `@EnableIntegrationGraphController` and `<int-http:graph-controller>` cases based on the `MockMvc`
JIRA: https://jira.spring.io/browse/INT-3989,
https://jira.spring.io/browse/INT-3990,
https://jira.spring.io/browse/INT-3988
INT-3989: Add `FileReadingMessageSource.WatchServiceDirectoryScanner`
* Deprecate top-level `WatchServiceDirectoryScanner` because of inconsistency around `Lifecycle` and shared `directory` property
* Copy/paste its logic into the `FileReadingMessageSource.WatchServiceDirectoryScanner` to hide that inconsistency, but still get a gain from the `WatchService` benefits
* Add support for the `StandardWatchEventKinds.ENTRY_MODIFY` and `StandardWatchEventKinds.ENTRY_DELETE` events in the `FileReadingMessageSource.WatchServiceDirectoryScanner`
* Introduce `useWatchService` option to switch to the internal `FileReadingMessageSource.WatchServiceDirectoryScanner`
* Make `CompositeFileListFilter` also as `ResettableFileListFilter`
* Deprecate weird `FileReadingMessageSource.onSend()` method and remove its usage from tests
* Modify `WatchServiceDirectoryScannerTests` for the new logic
* Document changes
Add `MODIFY` and `DELETE` test coverage
Optimize the `filesFromEvents()` logic replacing item with the fresh event sources.
Remove the item from the result set in case of `DELETE` event, because file removal generates both `MODIFY` and `DELETE` events.
* Add `FileReadingMessageSource.setWatchEvents` to allow to listen to the specific events,
not only `CREATE` or all of them.
* Modify tests and docs to reflect the new API
Address PR comments
* Improve `FileReadingMessageSource.setWatchEvents()`
* Add `file.exists()` before adding file from event.
Add more DEBUG logs into the `WatchServiceDirectoryScanner`
With the fact of those logs provide more optimizations:
* Don't register the same directory for watching:
- use the `ConcurrentMap<Path, WatchKey> pathKeys` to track registrations
- any modification within the directory causes the `ENTRY_MODIFY` for the directory as well.
So, skip such an event exactly for the directory during `walkDirectory`
* Add debug logs in case of `ENTRY_DELETE`
Since acks may arrive after the timeout and therefore won't be
delivered to the ackChannel, purge the channel to clear it
instead of waiting for the acks, before stubbing the template.
https://build.spring.io/browse/INT-B43-164/
* Fix CheckStyle for `System. out .println(` expression commenting out such a code line
* Fix generics in the `JdbcMessageStoreTests`
* Increase receive timeout in the `FileMessageHistoryTests`
* Change the `AsyncAmqpGatewayTests` logic to deal with the same channel for both `ack/nack`.
The `timeout` case without reply may end up with the `Consumer cancel`, therefore `nack` not `ack` like we expected
JIRA: https://jira.spring.io/browse/INT-3387,
https://jira.spring.io/browse/INT-3806
* Introduce
```
MessageGroupStore
void addMessagesToGroup(Object groupId, Message<?>... messages);
```
And implement it in all stores.
* Use new `addMessagesToGroup` where it is reasonable, e.g. `DelayHandler`
* Optimize test-case to use a new store method (where it is possible)
* Fix timing delays in the `JdbcMessageStoreTests`
* Introduce `PersistentMessageGroup`
* Add `AbstractMessageGroupStore#proxyMessageGroupForLazyLoad` to wrap the raw `MessageGroup` to the `PersistentMessageGroup` for lazy-load
* Rework `MessageGroupMetadata` do not be `immutable` and allow to store/restore in the `AbstractKeyValueMessageStore` only the `MessageGroupMetadata`
* Refactor `ResequencingMessageHandler` and `SequenceSizeReleaseStrategy` a bit for better performance when interact with the `MessageGroup`
* Add `AbstractMessageGroupStore#setLazyLoadMessageGroups` to switch off the `lazy-load` behavior and restore the previous full `MessageGroup` logic
* Add `What's New` note and `message-store.adoc` paragraph for the lazy-load functionality
`GroupType.PERSISTENT` and not lazy by default
PR Comments
Fix `JdbcMessageStoreTests` timing issues
Address PR comments
* Add performance test to the `ConfigurableMongoDbMessageGroupStoreTests`
* Add JavaDocs for the `MessageGroupFactory` methods
* Add `log4j.properties` into the `test` MongoDB module for better traceability
* Fix `JdbcMessageStore#getOneMessageFromGroup()` over the `doPollForMessage()` delegation.
The `jdbcTemplate.queryForObject()` requires exactly one and only one raw in `resultSet`
* Add performance test results into the `message-store.adoc`
JIRA: https://jira.spring.io/browse/INT-4001
Since all other Spring Framework components use the Jackson's `ObjectMapper` configuration by default as:
```
this.objectMapper.configure(MapperFeature.DEFAULT_VIEW_INCLUSION, false);
this.objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
```
It would be better to be consistent in Spring Integration, too.
* Add mention options to the `Jackson2JsonObjectMapper` default's `ObjectMapper`
* Add on more constructor into the `Jackson2JsonMessageParser` to allow to inject customized `Jackson2JsonObjectMapper`
* Modify a couple tests to reflect the change
* Reformat code style in the `AbstractJsonInboundMessageMapperTests` for better readability
**The Migration Guide note follows up**
JIRA: https://jira.spring.io/browse/INT-3999
Since the scheduled tasks may live for a long time it can finish
with the `OutOfMemory` if we use the direct reference to big objects, like `Message<?>`.
* Fix `AbstractCorrelatingMessageHandler` to deal only with the `groupId`
from the `scheduleGroupToForceComplete()` when we `schedule` `Runnable` for the `forceRelease` logic.
* Fix `DelayHandler` to deal only with `messageId` in the `releaseMessageAfterDelay()`, when we
`schedule` `Runnable` for the `releaseMessageAfterDelay`.
* Since the logic hasn't been changed for those components, there is no any new test.
There is just enough to be sure that all existing tests are fine.
**Cherry-pick to 4.0.x, 4.1.x, 4.2.x**
Optimise the release task for the `SimpleMessageStore` case
JIRA: https://jira.spring.io/browse/INT-3998
Do not modify interceptors from the `AbstractMessageChannel`.
They must be declared as beans, too.
Fix [UnusedImport] in the `EnableIntegrationTests`
Doc Polishing
https://build.spring.io/browse/INT-SONAR-1700/
We set up some stubbing on the `AsyncAmqpTemplate` to test nacks
which are not easy to generate on a real broker.
However, some acks might not have been consumed yet - this can cause
partial stubbing errors, depending on timing.
Be sure to consume all acks before stubbing the template.
JIRA: https://jira.spring.io/browse/INT-3996
One of the query provider implementations was missing. To avoid a maintenance
nightmare, simply reference the interface's javadoc which lists all known
implementations.
* Simple `JdbcChannelMessageStore` JavaDocs polishing
* Add `LogAdjustingTestSupport` to the `StompIntegrationTests` to trace failures in the future.
* Also change the test `Start/Stop` messages to the `WARN` level in the `LogAdjustingTestSupport`, because `DEBUG` doesn't work everywhere.
Maybe some logging systems mix misconfiguration, like we have in the WebSocket modules with the Embedded Tomcat
JIRA: https://jira.spring.io/browse/INT-3980
When we declare our components via `@Bean` (or `<bean>`) the requirements for
the `@Component` (`@MessageEndpoint`) looks redundant and sometimes even dangerous,
when we use `@ComponentScan`, too.
* Remove the `@Component` restriction logic from the `MessagingAnnotationPostProcessor`
* Ensure that tests pass
(We may consider to backport afterwards)
Add `requireComponentAnnotation` logic
* Introduce `spring.integration.messagingAnnotations.require.componentAnnotation` property for `spring.integration.properties` as `false` by default
* Add `MessagingAnnotationPostProcessor#setRequireComponentAnnotation()` to accept the value from the `spring.integration.messagingAnnotations.require.componentAnnotation`
* Fix `integraton` typo everywhere
* Document the change in the `What's New` and in the `configuration.adoc`
* Ensure that logic works properly (no messaging endpoints populated) with the `spring.integration.messagingAnnotations.require.componentAnnotation = true` and "unannotated" `AnnotatedEndpoint2` in the `AnnotatedEndpointActivationTests`
This PR also fixes: https://jira.spring.io/browse/INT-3962
Fix issues according Travis report
Doc Polishing
