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`
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/store/AbstractMessageGroupStore.java
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/store/AbstractMessageGroupStore.java
src/reference/asciidoc/aggregator.adoc
src/reference/asciidoc/resequencer.adoc
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/store/AbstractMessageGroupStore.java
spring-integration-core/src/main/java/org/springframework/integration/store/MessageGroupStore.java
spring-integration-mongodb/src/main/java/org/springframework/integration/mongodb/store/ConfigurableMongoDbMessageStore.java
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-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-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**
Conflicts:
spring-integration-core/src/test/java/org/springframework/integration/handler/DelayHandlerTests.java
Resolved
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`.
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/handler/DelayHandler.java
spring-integration-core/src/test/java/org/springframework/integration/handler/DelayHandlerTests.java
JIRA: https://jira.spring.io/browse/INT-3565
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.
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/config/AbstractSimpleMessageHandlerFactoryBean.java
Resolved.
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__
Conflicts:
spring-integration-core/src/test/java/org/springframework/integration/channel/registry/HeaderChannelRegistryTests.java
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
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/aggregator/AbstractCorrelatingMessageHandler.java
spring-integration-core/src/main/java/org/springframework/integration/aggregator/SequenceSizeReleaseStrategy.java
spring-integration-core/src/main/java/org/springframework/integration/config/GlobalChannelInterceptorProcessor.java
spring-integration-redis/src/main/java/org/springframework/integration/redis/store/RedisChannelPriorityMessageStore.java
JIRA: https://jira.spring.io/browse/INT-3423
Consider a message containing "one one" and a splitter
with expression "payload.split(' ')", only one message
is emitted.
The default Collection created by SpEL is a HashSet.
Change the ExpressionEvaluatingSplitter to expect a
List instead of a Collection.
Conflicts:
spring-integration-core/src/test/java/org/springframework/integration/splitter/SpelSplitterIntegrationTests.java
JIRA: https://jira.spring.io/browse/INT-3410
When running a fixed thread pool with a bound queue,
and CALLER_RUNS execution rejection policy, it
was possible to deadlock the IO selector thread.
Add a `CompositeExecutor` to use different threads for
IO to those used for message assembly.
Add a `CallerBlocksPolicy` to block the invoking thread
(for a specified time) if the pool is exhausted.
Add documentation.
Polishing
Also add another control-bus test.
Conflicts:
spring-integration-core/src/test/java/org/springframework/integration/config/xml/ControlBusTests.java
Resolved.
JIRA: https://jira.spring.io/browse/INT-3316
The `SimpleTypeConverter` delegate uses property editors
which are not thread safe. We protect against concurrent
access when the source is not a String, but when a String,
we delegate to the `STC`.
Synchronize access to the `STC.convertIfNecessary()` method.
JIRA: https://jira.springsource.org/browse/INT-3298
Emit a WARN log whenever the `ReleaseStrategyFactoryBean`
falls back to using the `SequenceSizeReleaseStrategy`.
This will happen if no method name is provided and no
annotated method is found, or a null reference is provided.
JIRA: https://jira.springsource.org/browse/INT-3300
The change introduced by https://jira.springsource.org/browse/INT-3147
(Registration of `MessageSource<?>` as a bean with suffix `.source`) broke
the case where `MessageSource<?>` is a reference to an existing bean.
Add check to the `AbstractPollingInboundChannelAdapterParser` for the type
of `source` and apply the appropriate logic.
Conflicts:
spring-integration-core/src/test/java/org/springframework/integration/config/ChannelAdapterParserTests.java
Resolved.
JIRA: https://jira.springsource.org/browse/INT-3252
Remove the use of `SecureRandom.generateSeed()` which is not
supported on some platforms.
Note: While this change does not reflect the custom IBM
code noted in the JIRA issue, it does revert the initial
SecureRandom generation to use the same code as
UUID.randomUUID(), so the expectation is that this will
work fine on zOS.
JIRA: https://jira.springsource.org/browse/INT-3240
Spring Integration 3.0 introduced registration of `MessageSource`s as beans
with an `id` based on the adapter `id` or, as a fallback, generated from
the `MessageSource` class name and the suffix `.source`.
But since that bean wasn't registered as a bean with the generated name (because the suffix was added),
subsequent elements get the same source bean name. This meant that
several anonymous `inbound-channel-adapter` with the same type (`file:`, `ftp:`, `twitter:` etc.)
caused an issue, when the same `MessageSource` bean was used by several `SourcePollingChannelAdapter` beans.
Fix the issue for fallback name generation by using the `SourcePollingChannelAdapterFactoryBean` class name.
Since that is registered, the source will always get a unique name, regardless of whether an id is provided.
Remove warning from BFCR if there is no HeaderChannelRegistry in
the bean factory. Change the log to DEBUG and remove the stack
trace.
Instead, update the Exception message when a channel name can't be
resolved to a channel to indicate that there is no registry.
JIRA: https://jira.springsource.org/browse/INT-3248
JIRA: https://jira.springsource.org/browse/INT-3235
Unable to programmatically wire header expressions or method-specific
properties into a GatewayProxyFactoryBean.
The GPFB has public methods that take arguments of
this type.
Make the class public instead of package-protected.
Add a test case.
JIRA: https://jira.springsource.org/browse/INT-3227
In MessagingTemplate.TemporaryReplyChannel, it was possible
the `clientHasReceived` boolean could be set by the other
thread after normal message receipt, but before the sender
tests it for the purpose of emitting a duplicate reply log
message.
Capture the boolean value of `clientHasReceived` before
counting down the latch.
JIRA: https://jira.springsource.org/browse/INT-3006
* Add integration properties `channels.maxUnicastSubscribers` and `channels.maxBroadcastSubscribers`
with default value to `Integer.MAX_VALUE`
* Add SpEL value resolution for those default values from parsers
* Deprecate similar properties from `ChannelInitializer`
INT-3006 `maxSubscribers` from channels' onInit()
* Move default init for `maxSubscribers` to the channels' `onInit()`
from `integrationProperties`, not from parsers
* extract `default` `integrationProperties` from static block in the `IntegrationProperties`
and use them as `default` on `IntegrationContextUtils#getIntegrationProperties`
* Add bean definition expression building to get the default values for `integration properties`
on bean building phase.
INT-3006: Add `taskScheduler.poolSize` property
INT-3006: Polishing
JIRA: https://jira.springsource.org/browse/INT-3216
Previously, After a group has been selected for completion
by the reaper, if the group is otherwise completed before
the reap AND expireGroupsOnCompletion is true AND a new
group with the same ID is created, ALL in the same millisecond,
AND the group creation timestamp is used for the reap criteria,
the new group will be incorrectly reaped.
Also, for a simple MGS, it was not necessary to re-fetch the group
if the group has already been marked complete.
- Defer reaping if the group is already complete (unless it's empty).
- Verify the timestamp hasn't changed (indicating a new group)
Add tests
- Verify no refetch of a complete SMG
- Verify no reap of a complete group (after refetch)
- Verify no reap when the timestamp changed
JIRA: https://jira.springsource.org/browse/INT-3055
* Add to HTTP Outbound Endpoint `uri-variables-expression`
* Add mutually exclusive check for `uri-variables-expression` with `<uri-variable>`
* Tests and Docs
INT-3055: Fixes
* `ExpressionEvalMap` now can apply `Map<String, Object>`,
but the value must have a `String` or `Expression` type.
Polishing
INT-3055 Doc Polishing
JIRA: https://jira.springsource.org/browse/INT-3213
Backwards reference from ....support.channel to
....channel.registry (BeanFactoryChannelResolver).
- Move the registry interface to ....support.channel
- Move the implementation to ....channel
JIRA: https://jira.springsource.org/browse/INT-3212
INT-3212 Fix Failing TCP Test
TcpNioConnections can deadlock when a fixed thread pool is being used.
The deadlock is detected after 60 seconds, but the test case failed
after 20 seconds - before the deadlock was detected.
Change the test to use a cached thread pool instead.
Also, increase concurrency by using threading in the test server
so each socket is handled on a separate thread.
Enchance connectionId to include both local and remote ports to
aid debugging.
Some minor formatting corrections.
JIRA: https://jira.springsource.org/browse/INT-3199
* Set `TypeDescriptor` to `Void.class` as default `targetParameterType` for falling-back
* Change `fall-thru` only to one method:
* Extract generic type from `Massage` parameter, so now
``` m1(Message<String> message);
m2(String payload);
```
are equal by `payload type` and similar POJO causes ambiguity configuration exception
INT-3199: Polishing and further fixing
* Address PR's comments
* Provide more friendly exception message for `Void.class` method
* Remove the logic around `@ServiceActivator`:
- one part was fixed within INT-3114
- another for `RequestReplyExchanger#exchange` doesn't make sense as it is good candidate
* Add fallback to `Iterator.class` method for `Iterable` payloads
* Add tests
Polishing
INT-3199: Add `handlerMessageMethods`
* Introduce separate properties:
- `handlerMessageMethods` for methods with `Message` parameter
- `handlerMethod`, if there is only one candidate after configuration
* Polishing several tests according new state of `MessagingMethodInvokerHelper`'s properties
Polishing
Revert `RequestReplyExchanger` fallback
Add `fallbackMessageMethods` processing
INT-3199 Polishing
Only revert to RequestReplyExchanger if there are ambiguous
fallback methods - if the target object is an RRE, it will always
have a candidate fallback (exchange).
Add more RRE tests.
Make ParametersWrapper a public inner class - it's only used
within the context of a process() call. Making it public allows
SpEL to access its properties without reflection.
Allows reply channel resolution after a message has been serialized
somewhere in a flow. Previously, the reply channel was lost.
With this change, the reply channel can be registered and the header
becomes a string (channel name) that can be serialized.
JIRA: https://jira.springsource.org/browse/INT-2269
INT-2269 Rename Registry to HeaderChannelRegistry
- Extract interface
- DefaultHeaderChannelRgistry
INT-2269 Polishing; PR Comments
- Add errorChannel registration as well.
INT-2269 HeaderChannelRegistry - Fix
The internal BridgeHandler in MessagingGatewaySupport did not have
a channel resolver. When a reply was explicitly routed to the gateway's
reply channel, the String representation of the reply channel could
not be resolved to a channel.
Set the BeanFactory on the bridge handler.
Add tests.
INT-2269 HeaderChannelRegistry - Fix JMS/Enricher
The JMS inbound gateway and ContentEnricher instantiate a
MessagingGatewaySupport internally it does not get a
reference to the BeanFactory. This means that the internal
BridgeHandler cannot resolve the String representation of
the reply channel to a channel.
Make ChannelPublishingJmsMessageListener BeanFactory aware, and
propagate the bean factory to the MGS.
Set the MGS bean factory in the ContentEnricher (which is already
BFA).
INT-2269: Polishing
Enable the use of multiple JSch channels over a
single connection.
JIRA: https://jira.springsource.org/browse/INT-3047
INT-3047: Polishing locks logic
INT-3047 SFTP Reset Cache; Quiesce Shared Sessions
Support resetCache() on the CachingSessionFactory
- reset a shared JSch session so it is reestablished on next use
- immediately close idle sessions
- close in-use sessions as they are returned
- close the channel when an SftpSession is closed and a shared JSch is being used
- physically close a shared JSch session only when the last channel is closed
Polishing
Forgot to save the ftp.xml.
Change CachedSession.epoch to created.
INT-3047 Polishing - PR Comments
- Also add missing docs for `preserve-timestamp`
INT-3047 Polish - PR Comments
Also change epoch to nanoseconds and use a simple != comparison with the
epoch in which a session was created.
JIRA: https://jira.springsource.org/browse/INT-3017
* Add parsers tests and integration tests
* Polishing Redis XSD
* Fix `JmsMessageDrivenEndpointParser` `LifeCycle` attributes
* Catch `RedisSystemException` after `this.boundListOperations.rightPop`.
It maybe an exception about 'connection closed'.
If the `RedisQueueMessageDrivenEndpoint` is 'active' this exception is rethrown,
otherwise just logged under error category.
* Add Redis queue components docs
JIRA: https://jira.springsource.org/browse/INT-3019
INT-3017 Doc Polishing
