JIRA: https://jira.spring.io/browse/INT-3698
The `HttpRequestExecutingMessageHandler` added two internal `Converters` to the `ConversionService` before.
In case of parent-child environment it causes memory leak: closing of child context doesn't release
`HttpRequestExecutingMessageHandler` instances, because those internal `Converters` aren't `static`, hence bounded to outer instance.
Actually after introduction since `4.0` version to the `HttpRequestExecutingMessageHandler` the code like:
```
Assert.isTrue(expectedResponseType instanceof Class<?>
|| expectedResponseType instanceof String
|| expectedResponseType instanceof ParameterizedTypeReference,
"'expectedResponseType' can be an instance of 'Class<?>', 'String' or 'ParameterizedTypeReference<?>'.");
if (expectedResponseType instanceof String && StringUtils.hasText((String) expectedResponseType)){
expectedResponseType = ClassUtils.forName((String) expectedResponseType, ClassUtils.getDefaultClassLoader());
}
```
These converters are redundant.
In addition remove the `expected type` for the `uriVariablesExpression` evaluation to avoid `MapToMapConverter`.
**Cherry-pick to 4.1.x, 4.0.x**
INT-3698: Provide robust logic for the `uriExpression` and `httpMethodExpression`
Make some polishing around `Assert`s, when `IllegalStateException` must be presented instead of `IllegalArgumentException`
for the expression evaluation results.
Polishing
Conflicts:
spring-integration-http/src/test/java/org/springframework/integration/http/config/OutboundResponseTypeTests.java
Resolved.
This commit updates the version of Spring Web Services to
2.2.1.RELEASE. The fix for SWS-892 means that in the event of an
interceptor failing to handle a request, the request is no longer
sent. The interceptor in UriVariableTests has been updated to return
true, indicating that the request has been handled and should be
sent.
JIRA: https://jira.spring.io/browse/INT-3667
* fix `RedisLockRegistry.tryLock` memory leaks using 2 different thread local internal storages:
hard references for locked locks and weak references (optional) for others, weak references are used for lock obtaining optimization -
thread will get same `RedisLock` object for certain key before locking and after unlocking (if variable still exists)
* add `RedisLockRegistry.useWeakReferences` property for enable thread local weak references storage for unlocked locks, disabled by default
* fix `RedisLockRegistry$RedisLock.obtainLock` improper expire time update (expire time was updated on every attempt to get lock)
* update `RedisLockRegistry` tests
JIRA: https://jira.spring.io/browse/INT-3669
Previously the `DelayHandler` incorrectly calculated a `delay` for values which are of the `Date` time.
It always used `new Date()` even for rescheduling for persisted messages.
* Fix `DelayHandler` to calculate `delays` against the `requestDate` of the delayed Message
* In addition fix the expression evaluation root object, when for rescheduling it was the message with `DelayedMessageWrapper` payload instead of original message.
**Cherry-pick to 3.0.x, 4.0.x, 4.1.x**
The "transaction" synchronization tests use a `QueueChannel`.
The payload is a live reference to the Redis object.
It is possible that the test for the returned size occurs after
the "transaction" commits.
Change the tests to extract the size() on the poller thread so
that the size is always captured before the "transaction" commits.
JIRA: https://jira.spring.io/browse/INT-3614
The `extractPayload` is present in the namespace support for `<int-jms:inbound-channel-adapter>`,
but nor `JmsInboundChannelAdapterParser`, neither `JmsDestinationPollingSource` take care of that value.
To be consistent with `<int-jms:message-driven-channel-adapter>` and documentation, introduce that option for
`JmsDestinationPollingSource` and populate it from the `JmsInboundChannelAdapterParser`.
JIRA: https://jira.spring.io/browse/INT-3620
Add `setShouldAppendNewLine(boolean shouldAppendNewLine)` method to the
`FileWritingMessageHandler` class. Added similar test methods to the
`FileWritingMessageHandlerTests` class.
INT-3620: `appendNewLine` just only for `FileExistsMode.APPEND`
Also add `appendNewLine` for `File` payload
INT-3620: `appendNewLine` for any `fileExistsMode`
JIRA: https://jira.spring.io/browse/INT-3604
There is no test-case to cover the issue, because it isn't so easy to emulate the network glitch between `setIfAbsent` and `expire`
JIRA: https://jira.spring.io/browse/INT-3598
- Force the first two constructor args to be of type `String`.
- When no client factory, add one in the parser rather than selecing an alternate ctor.
Conflicts:
spring-integration-mqtt/src/main/java/org/springframework/integration/mqtt/config/xml/MqttParserUtils.java
spring-integration-mqtt/src/test/java/org/springframework/integration/mqtt/config/xml/MqttMessageDrivenChannelAdapterParserTests-context.xml
spring-integration-mqtt/src/test/java/org/springframework/integration/mqtt/config/xml/MqttMessageDrivenChannelAdapterParserTests.java
Remove test for unsupported `empty topics` functionality
JIRA: https://jira.spring.io/browse/INT-3587
There is no ability to use own local LockRegistry to avoid overlapping of produced ReentrantLock objects, it can happens if used unique keys have same masked value for DefaultLockRegistry.
Add a constructor to allow the configuration of a lock registry with a differnt number of locks than the default.
JIRA: https://jira.spring.io/browse/INT-3560
Previously, messages arriving at the delayer before the
the context was initialized would be emitted twice after
the context `refresh()` or a JMX invocation of `reschedulePersistedMessages()`.
When using a `SimpleMessageStore`, the "re" scheduled
message from the context refreshed event (or a JMX invocation)
would be re-handled unconditionally.
This was due to incorrect logic to handle the way the `SMS` stores messages.
Change the logic to correctly handle (ignore) duplicate scheduled
releases when using `SMS`.
JIRA: https://jira.spring.io/browse/INT-3572
Previously, a blocking queue was used to hold seen files; this was used to enable
FIFO when a max capacity is set.
When used with no capacity, a queue is not needed; also the `contains` operation
on a queue requires a linear search which does not scale well for a large number
of files.
Use a `HashSet` instead to significantly improve the `contains` performance.
Only maintain a queue if a max capacity is set.
Fix `AcceptOnceFileListFilterTests` to be compatible with Java < 8
JIRA: https://jira.spring.io/browse/INT-3565
Cast to `IntegrationObjectSupport` fails if the handler is
already proxied in `AbstractSimpleMessageHandlerFactoryBean`.
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/config/AbstractSimpleMessageHandlerFactoryBean.java
Resolved.
INT-3565 Polishing
- Fix test.
- enhance test to show that directly bound message handler beans are not advised if already proxied.
JIRA: https://jira.spring.io/browse/INT-3545
Previously, the `DefaultHeaderChannelRegistry` was auto-started.
This caused the reaper to run and eventually start all the
`taskScheduler` threads, even if the registry was not being used.
- Defer the `start()` until the first channel is stored.
- Do not start the reaper if the bean has been explicitly stopped.
- Deprecate the implementation of `SmartLifecycle`.
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/channel/DefaultHeaderChannelRegistry.java
Resolved.
__cherry-pick to 3.0.x__
JIRA: https://jira.spring.io/browse/INT-3543
Quoting Sam Brannen:
> However, one should *never* programmatically close the injected application context in a test,
since the Spring TestContext Framework caches all contexts across the entire JVM process.
If you need to close a context after a test method or test class for some reason,
the only supported and reliable mechanism is `@DirtiesContext`.
**Cherry-pick to 4.0.x**
JIRA: https://jira.spring.io/browse/INT-3539
Previously the `ChannelSecurityInterceptorBeanPostProcessor` eagerly loaded all beans from its `afterPropertiesSet`
to retrieve the `ChannelSecurityInterceptor`s. According to the `BeanPostProcessor` nature the `afterPropertiesSet` hook isn't legitimate.
It may cause some bad side-effects for other beans, which might not been initialized yet.
Rework `ChannelSecurityInterceptorBeanPostProcessor` to accept `Collection<ChannelSecurityInterceptor>` in the ctor.
Rework `SecurityIntegrationConfigurationInitializer` to iterate over `BeanDefinition`s to determine those of them, which
are `ChannelSecurityInterceptor` or `ChannelSecurityInterceptorFactoryBean`.
**Cherry-pick to 4.0.x**
JIRA: https://jira.spring.io/browse/INT-3536
The fix for opening multiple IMAP connections in the idle
adapter inadvertently removed the check for the store being
open.
Add `connectStoreIfNecessary()` and test case.
JIRA: https://jira.spring.io/browse/INT-3528
Use `min` and `max` methods instead of sorting an entire collection to get the minimum or maximum element.
Change other inline `Comparator<?>`s to the `final` fields
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/aggregator/AbstractCorrelatingMessageHandler.java
JIRA: https://jira.spring.io/browse/INT-3526
Previously, the URI in the exception message is the raw
URI with placeholders, if present.
Use the expanded URI in the message instead.
(cherry picked from commit 113716e)
JIRA: https://jira.spring.io/browse/INT-3524
Backport to 4.0 schemas.
A number of references (expected-type) still referred to
the Spring Integration 3.0 MessageChanel.
