* `JmsOutboundGatewayTests`: just increase timeouts. Looks like embedded ActiveMQ Broker takes more time to interact on high-loaded builds
* `TcpOutboundGatewayTests`: Rework the race condition fix to the atomic `remoteTimeout` change using mocks
* 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.
The `ExtractRequestReplyPayloadTests` uses `3000` for `reply-timeout`.
This value might not be enough on high-loaded environment such a CI Server:
https://build.spring.io/browse/INT-B41-450
* Increase the timeouts for adapters to the `10000` to have more chances to pass on the CI.
* Some simple code polishing for the `ExtractRequestReplyPayloadTests`
JIRA: https://jira.spring.io/browse/INT-3860
Similar to INT-3794, if some other process is bound to all adapters
$ lsof -i tcp -nP | grep 9000
java 6604 grussell 380u IPv6 0x407e749ec47fa337 0t0 TCP *:9000 (LISTEN)
The socket utils reports that the localhost is available for binding; however, the test then
binds to all adapters.
1. Where (easily) possible, change tests to use port=0 and let the OS choose.
2. For other tests, use high-numbered ports.
3. Change tests to explicitly bind to localhost (like the utility did).
4. Fix `tcpOutboundGatewayInsideChain` test to use the correct port.
Polishing - Fix Travis
Bind SOLingerTests to localhost.
Since we're using port 0, we have to wait until listening before calling getPort().
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.
JIRA: https://jira.spring.io/browse/INT-3849
A file inbound adapter with just a `filter` attribute (no implied filter attributes)
did not get its filter injected.
The parser took an early exit from the filter configuration if none of the implied
filter attributes were specified.
Work around is to explicitly set `ignore-hidden="true"`.
JIRA: https://jira.spring.io/browse/INT-3848
When the `ConsumerEndpointFactoryBean` is created programmatically
the `beanName` property may be missed and the `catch` for the `NPE`
just hides an issue with the `DEBUG` log message.
Add check for the `null` on the `bean` and log the issue on ERROR level.
**Cherry-pick to the 4.1.x, 4.0.x and 3.0.x**
JIRA: https://jira.spring.io/browse/INT-3841
Previously the `isPubSub` was as `Boolean` object and `null` by default.
Convert it to the primitive to achieve the `false` logic by default as expected.
JIRA: https://jira.spring.io/browse/INT-3840
* In addition: fix some typos in the `SftpInboundRemoteFileSystemSynchronizerTests`
**Cherry-pick to 4.1.x**
JIRA: https://jira.spring.io/browse/INT-3827
Provide a hook to enable removing a file from an `AcceptOnceFileListFilter`,
for example after a message processing failure.
Make the `CompositeFileListFilter` a `ReversibleFileListFilter` so it can
delegate to any of its composed filters that are reversible.
INT-3827: Polishing - PR Comments
JIRA: https://jira.spring.io/browse/INT-3837
INT-3103 introduced exception propagation to waiting gateway threads.
However, `SocketTimeoutException`s were not propagated (in all cases
since 4.2 and for single-use sockets since 3.0).
JIRA: https://jira.spring.io/browse/INT-3829
Alongside with the `@Bean` definition we can use, for example, `@Profile` `@Conditional` annotation.
And the final bean won't be populated to the context.
When messaging annotations are present on `@Bean`s, a second bean for the endpoint consumer
is created.
Previously, the `MessagingAnnotationPostProcessor` did not check if the `@Bean` was present;
hence we ended up with a `NoSuchBeanDefinitionException`
* Add appropriate `try...catch(NoSuchBeanDefinitionException)` to the `AbstractMethodAnnotationPostProcessor` and
`InboundChannelAdapterAnnotationPostProcessor` to skip further endpoint processing if the bean does not exist.
Add DEBUG message for the skipped beans
Polishing
JIRA: https://jira.spring.io/browse/INT-3826
Application Context would not initialize with annotation without attributes.
Defaults were wrong; metrics factory bean name.
Make `IntegrationManagementConfigurer` more robust for the external options
JIRA: https://jira.spring.io/browse/INT-3820
Some Proxy may be based on the specif non-user classes and advised with
the provided end-user interfaces.
The best sample is `@Repository` from Spring Data projects.
In this case the `MessagingMethodInvokerHelper` just missed the user interfaces
to consider for the candidate methods or thrown an `Exception` like `NoSuchMethodError`.
* Add `((Advised) targetObject).getProxiedInterfaces()` for the scanning algorithm
* Move the `UniqueMethodFilter` to the internal `Set<Method>` to allow iteration
and filtering for methods from the `targetClass` as well as from all those user interfaces
* Add Spring JPA repository test-case
* Polishing form some time-weak tests
Revert MessagingMethodInvokerHelper
INT-3820: Simple Proxy Interface Method Matching
No-risk solution for INT-3820.
Instead of considering all interfaces on the proxy, only look at proxy interfaces
for a single matching method name if we find no candidate or fallback methods.
Consider the complete solution for 4.3.
Add `Message<?>` method distinguishing
JIRA: https://jira.spring.io/browse/INT-3821
The `MessagingException` provides an empty String for its `NestedRuntimeException`
for those ctors which are without `description` argument.
The `NestedRuntimeException` uses `NestedExceptionUtils.buildMessage` for `getMessage()` implementation
and the algorithm there is based on the `message != null` condition to build the first part of the nested
cascade. In the case of empty String we end up with useless ";" part in the StackTrace logs.
Fix Framework classes to use the `MessagingException` ctor with particular description.
