JIRA: https://jira.spring.io/browse/INT-3950
Previously there was a mention of the `MessageGroupStore.expireMessageGroup(groupId)` which just doesn't existing
in the Framework and never has been there.
* Fix the documentation for the existing `MessageGroupStore.expireMessageGroups(timeout)`.
Although the mention there of `Control Bus` requires to have `@ManagedOperation` on the method.
* Add `@ManagedOperation` for the `MessageGroupStore.expireMessageGroups(timeout)` and confirm with the test-case: `AggregatorWithMessageStoreParserTests`
* Fix the same docs in the XSD for `<aggregator>`
* Fix other typos in the `aggregator.adoc` and `resequencer.adoc`
JIRA: https://jira.spring.io/browse/INT-3816
Add `cause` `supperclass` mapping ability to the `ErrorMessageExceptionTypeRouter`
Address PR comments:
Introduce `classNameMappings` to store exception classes on the mapping population.
Override all `@ManagedOperation` s to modify `classNameMappings` as well.
Address PR comments:
* Remove redundant local variable
* Fix concurrency access around `channelMapping`
* Add `ClassNotFoundException` test for the `ErrorMessageExceptionTypeRouter`
* Add `What's New` note about the `ClassNotFoundException` during init
Get rid of `synchronized`, use atomic changes
Additional polishing to avoid `ConcurrentModificationException `
Polishing
JIRA: https://jira.spring.io/browse/INT-3898
Some XML validator like `xercesImpl` doesn't allow `minOccurs` and `maxOccurs` on the `<xsd:all`.
* Remove them in favor of `minOccurs`/`maxOccurs` on the nested elements.
* Add `<poller>` for the `<int-jmx:notification-publishing-channel-adapter>`
JIRA: https://jira.spring.io/browse/INT-3920
Remove package and private protection from the message handler `FactoryBean` hierarchy.
Ease the creation of subclasses, for example, it was impossible to subclass
the `SplitterFactoryBean` to support default, expression, or file splitter here:
43c8c041d7 (diff-bb5468e093538789dcde1b222fe90693R62)
* Fix JavaDocs for published methods.
JIRAs:
https://jira.spring.io/browse/INT-3830https://jira.spring.io/browse/INT-3523https://jira.spring.io/browse/INT-3846
* Fix the OOM condition, when we `release()` `UpperBound` independently of the previous `remove` result (https://jira.spring.io/browse/INT-3846)
* Fix "confuse" around `groupCapacity`, when we really didn't care about individual groups (https://jira.spring.io/browse/INT-3523)
* Add `upperBoundTimeout` to have a hook to wait some time for the empty slot in the store (https://jira.spring.io/browse/INT-3830)
* Fix some JavaDocs warnings
* Fix some typos
* Fix inconsistency in the `DelayHandler` around `removeMessageFromGroup` when `MS` is `SimpleMessageStore`
* Remove `UpperBound.release()` operation from `SimpleMessageStore.removeGroup()`.
The waiting process should worry about the new `UpperBound` instance.
Some other polishing
`tryAcquire` outside of the `lock`
Move `tryAcquire` within the `addMessageToGroup` outside of `lock`.
But do that only for groups which already exist.
For the new groups we have a fresh `UpperBound`, so no need to worry about dead lock and
we can obtain a permit immediately.
SimpleMessageGroup: BlockingQueue -> LinkedHashSet
`SimpleMessageStore`: use "unsynchonized" `SimpleMessageGroup`
Make some synchronization fixes according to the migration to the `LinkedHashSet`
Avoid extra `Collection`
`ResequencingMessageHandler`: compare `size()` of collections instead of `containsAll()`
Fix `ConcurrentModificationException` in the `AbstractKeyValueMessageStore`
Add `SimpleMessageStore.clearMessageGroup()`
Accept polishing and fix `RedisChannelMessageStoreTests`
`@Deprecated` `MessageGroupStore.removeMessageFromGroup()`
Fix some typos
Introduce `SimpleMessageGroupFactory`
Extract `MessageGroupFactory` and address PR comments
Polishing after rebase
JavaDocs and Reference Manual
Fix JavaDocs
JIRA: https://jira.spring.io/browse/INT-3926
* Add `<poller>` for all `<outbound-adapter(gateway)>`
* Add/modify tests for `<queue>` as an input channel and particular `<poller>`
* Move XSD from the `xml` package to the `config` level to achieve the consistency throughout the project.
JIRA: https://jira.spring.io/browse/INT-3916
The `JpaOutboundGatewayFactoryBean` used CTOR injection for the `JpaExecutor`.
That one, in turn, uses CTOR injection for the `EntityManagerFactory`.
Such a dependency may cause the `early bean instantiating` in case of `AbstractAutowireCapableBeanFactory.getSingletonFactoryBeanForTypeCheck()`.
And we end up with the `BeanCurrentlyInCreationException`.
Therefore no one `FactoryBean` should use CTOR injection if there is a potential hierarchical dependency.
NOTE: there is no tests on the matter, since we don't change the components behavior.
The `JPA` sample application will be changed to the Boot to track this fix.
**Cherry-pick to 4.2.x**
Address PR comments and fix other `FactoryBean`s for the same issue, when it is reasonable
Polishing
Address PR comments
Make setter `setSockJsTaskScheduler` as `public`
JIRA: https://jira.spring.io/browse/INT-3899
Previously, within `AbstractPollingEndpoint`, the `Poller` object was
created from `afterPropertiesSet()` as well as `start()` if previously `stopped()`
(`this.initialized == false`).
This precluded modification of the advice chain (e.g. in tests when using
`autoStartup == false`).
Move the poller creation to `start()` so that it is always created then, and does
not require a previous `stop()` to change the advice chain.
https://jira.spring.io/browse/INT-3665
Fixes according Travis report
Introduce `...ExpressionString(String)` setter
Some further fixes and polishing
Address PR comments
JIRA: https://jira.spring.io/browse/INT-3904
When we use the same expression several times, the SpEL engine cache an `accessor` after the first use.
The next evaluation just bypass `canRead()` and in case of JSON that mean that we don't check that the income has the field or not.
For this case the `read()` must return `TypedValue.NULL` instead of just `null`.
JIRA: https://jira.spring.io/browse/INT-799
Some test classes (e.g. `TestUtils`) were duplicated in core to avoid cyclic
dependency.
Now that core messaging has been moved to spring-messaging, it is possible
to remove the dependencies on `spring-integration-core` from `spring-integration-test`.
A few minor test cases have been moved to `spring-integration-core`.
The simple polishing to the `build.gradle` and `ServiceActivatorOnMockitoMockTests`
JIRA: https://jira.spring.io/browse/INT-3534
Previously the `MethodInvokingMessageListProcessor` copied `Collection<Message<?>>`
in its `process()` method for the `delegate` to a new `Collection` unconditionally.
To improve performance, the collection is no longer copied unconditionally
in the `ExpressionEvaluatingMessageGroupProcessor`.
Also add an `important` note to the `aggregator.adoc` about the restriction with `unmodifiableCollection`.
JIRA: https://jira.spring.io/browse/INT-3895
* `@Ignore` `DelayerUsageTests.testDelayWithCustomScheduler()` as very weak test. (We can consider it to remove at all: doesn't test anything from our side)
* Add `LogAdjustingTestSupport` diagnostic to the `OutboundGatewayFunctionTests`
Tentative commit to see more logs from Travis
Additional diagnostics
More STOMP Diagnostics
JIRA: https://jira.spring.io/browse/INT-3884
Previously, an outbound gateway within a chain allowed a `reply-channel` attribute
but it was ignored. The gateway's output channel is set to send the message to
the next element in the chain, or the chain's output channel if the gateway is
the last element.
Tighten the parser logic to detect and disallow a reply channel within a chain.
Polishing
JIRA: https://jira.spring.io/browse/INT-3823
The test stops the endpoint.
The previous poller thread can 'steal' the `input` message, but since
it is interrupted, it can't send the message to the `publishedChannel`.
Add logic to wait until the previous poller has been interrupted in `receive()`.
Increase the endpoint `receiveTimeout` to ensure the thread will be interrupted.
Bump SF Version to 4.2.3
Remove `TRACE` logging from the `EnableIntegrationTests` since we have the fix already
Make some optimization around `@DirtiesContext`
* `ClientWebSocketContainer`: add some synchronization to avoid race conditions: https://build.spring.io/browse/INT-B41-492
* `TomcatWebSocketTestServer`: convert to `0` port to rely on the OS resolution for `localPort`
* Add `LogAdjustingTestSupport` for STOMP test
* `SftpServerTests`: use `0` port to rely on the OS resolution for `localPort`
* `ImapMailReceiver`, `OutboundGatewayFunctionTests` (JMS), `CachingClientConnectionFactoryTests`,
`AsyncGatewayTests`, `AsyncMessagingTemplateTests`, `GatewayParserTests`, `PriorityChannelTests`, `AggregatorIntegrationTests`: increase timeout
* `EnableIntegrationTests`: use `LogAdjustingTestSupport`
* `FileOutboundChannelAdapterParserTests`: rework `Thread.sleep()` with `CountDownLatch`
* `ConnectionToConnectionTests`: increase timeout and count iteration. Previously with `1sec` we may lose some events. And we can't just rely on the `10sec`,
because the last iteration will be so long
* `TcpOutboundGatewayTests`: `500ms` is so big timeout to wait for the `Exception` that in the high load environment we can yield to other Thread so long.
Like in our case to `server` Thread to send the reply for us. Therefore decrease the Exception timeout to the `50ms` and increase server delay to `2sec`
* `StompInboundChannelAdapterWebSocketIntegrationTests`: remove `@Qualifier("taskScheduler")` as a potential candidate to test against latest SF changes.
We're fine with `SF-4.2.2` and it is just a test-case. So, I don't see reason to wait for their fix here.
STOMP: `session = null` in adapters for any transportError
Polishing
JIRA: https://jira.spring.io/browse/INT-3874
Previously the `IntegrationEvaluationContextFactoryBean` copied only those spel-functions which are defined
as beans in the ctx. Those which are specified through the `setFunctions` hasn't been copied from parent ctx to child.
This fix addresses and issue.
JIRA: https://jira.spring.io/browse/INT-3831
- Add `@IntegrationManagedResource`
- Suppress exporting as an endpoint
Fix `outputChannel` issue for anonymous `MessagingGatewaySupport`
INT-3831: Pure JavaConfig Test
INT-3831: Polishing
Check output channel name for anonymous message source metrics.
Don't use getter on MGS to avoid early channel resolution.
INT-3831: Fix Test - Avoid Second MBeanServer
Reference the `MBSFB` in the context rather than create a new `MBeanServer`.
Polishing
* Modify `ControlBusTests.testControlHeaderChannelReaper()` do not rely on the `timeout`.
Make artificial expiration for the entry in the `registry` to allow `reaper` to remove it according the test logic.
* Fix race condition around `gateway.setRemoteTimeout(5000);` in the `TcpOutboundGatewayTests`.
The problem was that the gateway is called concurrently and `setRemoteTimeout` might be changed before the `handleMessage()` even for the first attempt.