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.
JIRA: https://jira.spring.io/browse/INT-3857
Setter injection avoids early instantiation of FB properties.
Enhance aggregator parser tests to include several new properties to
check coverage in FB.
Clean up other tests.
Polishing - PR Comments
JIRA: https://jira.spring.io/browse/INT-3853
Previously the placeholder definitions for the Messaging Annotation weren't be resolved
if we use `<context:property-placeholder>` instead of `@PropertySource`.
Fix `MessagingAnnotationPostProcessor` and its "kindergarten" to use
`beanFactory.resolveEmbeddedValue()` instead of `environment.resolvePlaceholders()`.
JIRA: https://jira.spring.io/browse/INT-3852
Custom object names in `@IntegrationManagedResource` were ignored.
Some EIP objects were wrapped with their `Lifecycle` in order to expose
a single MBean with all attributes and operations.
This process "hid" the annotation so the object namer failed to detect the
presence of a custom object name or the other attributes.
Also, update the `@IntegrationManagedResource` to use the Spring 4.2 `@AliasFor` annotation.
INT-3852: Polishing
Polishing - Test with Proxy
JIRA: https://jira.spring.io/browse/INT-2541
The `IntegrationMBeanExporter` doesn't register any `@ManagedResource` automatically.
Its `autoDetection` is disabled by default.
Hence such a components like `AbstractMessageGroupStore`
or `WireTap` aren't exposed to the JMX by the `IntegrationMBeanExporter`.
From other side `MBeanExporterHelper` aims to help to avoid duplicate exposing if
an `MBeanExporter` is presented in the CTX.
But `MBeanExporterHelper` did that unconditionally just for the whole `org.springframework.integration` package.
Therefore components which aren't EIP ones aren't exposed to the JMX at all.
* Fix `MBeanExporterHelper` to deal for exclusion based on the `@IntegrationManagedResource` annotation.
* Remove `@IntegrationManagedResource` from those components which aren't EIP.
* Make some polishing in the JMX tests.
