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-3893
Polishing
Send on the calling thread if the executor is shut down.
Conflicts:
spring-integration-ip/src/test/java/org/springframework/integration/ip/udp/UdpChannelAdapterTests.java
Resolved.
JIRA: https://jira.spring.io/browse/INT-3885
Possible dropped reply, causing timeout.
WARN org.springframework.integration.jms.JmsOutboundGateway#1.replyListener-1 jms.JmsOutboundGateway:1202
- Failed to consume reply with correlationId 164a49bf-c41d-4c0b-b012-55deecf001d1_2
java.lang.RuntimeException: No sender waiting for reply
- Reproduced by running the test in a loop
- Cleaned up test to aid debugging - capture a unique message at each stage
- Added additional debug logging to th gateway
Polishing
(cherry picked from commit f1bd6e3)
(cherry picked from commit 6183f24)
JIRA: https://jira.spring.io/browse/INT-3859
The Java Mail `MessageCache.getMessageBySeqnum()` has the code:
````java
if (msgnum < 0) { // XXX - < 1 ?
if (logger.isLoggable(Level.FINE))
logger.fine("no message seqnum " + seqnum);
return null;
}
````
about which the `IMAPFolder.search` doesn't care:
````java
matchMsgs[i] = getMessageBySeqNumber(matches[i]);
````
therefore pops `null`s to the top for the `ImapMailReceiver`
* Fix `NPE` filtering the `Message[]` from `null` items
Note: its enough difficult to reproduce it because it isn't clear how we can end up with:
````java
if (seqnums[msgnum-1] > seqnum)
break; // message doesn't exist
````
in the `MessageCache`.
That's why there is no test-cases on the matter.
**Cherry-pick to 3.0.x**
Conflicts:
spring-integration-mail/src/main/java/org/springframework/integration/mail/ImapMailReceiver.java
Resolved.
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-3843
**Cherry-pick to the 3.0.x**
Conflicts:
spring-integration-ip/src/main/java/org/springframework/integration/ip/tcp/connection/TcpNioServerConnectionFactory.java
Resolved.
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.
INT-3841: Fix New Test
New test channel remains as a listener on the connection factory.
Conflicts:
spring-integration-amqp/src/test/java/org/springframework/integration/amqp/channel/ChannelTests.java
Resolved.
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).
Conflicts:
spring-integration-ip/src/test/java/org/springframework/integration/ip/tcp/TcpOutboundGatewayTests.java
Resolved.
Remove beanfactory from backported test.
JIRA: https://jira.spring.io/browse/INT-3767
The `JpaInboundChannelAdapterParser` has missed to parse `parameter-source`,
as well as the parser test-case has been missed.
In addition fix JPA xsd for wrong type references.
Conflicts:
spring-integration-jpa/src/test/java/org/springframework/integration/jpa/config/xml/JpaInboundChannelAdapterParserTests.xml
resolved.
JIRA: https://jira.spring.io/browse/INT-3751
Result was null when `executeScript()` was invoked with non-null variables.
When variable are provided, the result variable is stored in the provided bindings.
JIRA: https://jira.spring.io/browse/INT-3744
MimeMessages are copied to eagerly fetch IMAP messages, this process loses
the `receivedDate` property.
Keep a reference to the source Message and delegate to its `receiveDate()`.
Cover more "void" getters
JIRA: https://jira.spring.io/browse/INT-3700
Change to calculate proper syndicate entry date for comparison when
adding feeds for processing.
I have signed and agree to the terms of the SpringSource Individual
Contributor License Agreement.
unit test for recent changes to FeedEntryMessageSourceTests to verify
proper last seen date calculation.
updates for comments from code review
* newline at EOF on atom.xml
* removed question from code
* fetch files via classpath instead of file system
* 'else' on newline
* authorship on class
Polishing
Conflicts:
spring-integration-feed/src/test/java/org/springframework/integration/feed/config/FeedInboundChannelAdapterParserTests.java
Conflicts:
spring-integration-feed/src/main/java/org/springframework/integration/feed/inbound/FeedEntryMessageSource.java
spring-integration-feed/src/test/java/org/springframework/integration/feed/inbound/FeedEntryMessageSourceTests.java
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-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`.
Conflicts:
spring-integration-jms/src/main/java/org/springframework/integration/jms/JmsDestinationPollingSource.java
spring-integration-jms/src/main/java/org/springframework/integration/jms/config/JmsInboundChannelAdapterParser.java
spring-integration-jms/src/test/java/org/springframework/integration/jms/config/jmsInboundWithConnectionFactoryAndDestination.xml
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
@Rule used a 10 second connection timeout.
Polishing
Conflicts:
spring-integration-mongodb/src/test/java/org/springframework/integration/mongodb/rules/MongoDbAvailableRule.java
Accept changes according to the current version of Mongo driver
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
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-3501
There were several problems:
When a `Folder` is open, an activity on the `Store` opens a new
connection.
The `PingTask` called `isConnected()` on the store, creating a new
connection. The pings (NOOPs) were performed on this connection and
therefore did NOT cancel the `IDLE`.
In any case, the `IDLE` was issued on the folder not the store and
the only way to cancel that IDLE is to cause its `waitIfIdle()` to
be invoked. Conveniently, simply calling `isOpen()` invokes that
method and cancels the IDLE.
Finally, the `SimpleMessageCountListener` unnecessarily invoked
`message.getLineCount()` when a simple `folder.isOpen()` is
sufficient.
Fixes:
1. Do not invoke `openSession` if `this.folder` is not null.
2. Change the `PingTask` to simply invoke `isOpen()`.
3. Move the `PingTask to the receiver for a more efficient algorithm
instead of running on fixed interval. Rename it `IdleCanceler`.
4. Increase the PING timer from 10 to 120 seconds; add setters for it
and the `reconnectionDelay`.
TODO: Namespace support for 4.1. (Not to be back ported).
Add a test IMAP server (ported from Java DSL and enhanced to simulate IDLE
with a new message arriving for the first idle period.
INT-3501 Polishing - PR Comments
Polishing for `PoorMansMailServer` to get rid of `smtp` and `pop3` servers to avoid unnecessary Base64 dependency
Conflicts:
spring-integration-mail/src/main/java/org/springframework/integration/mail/ImapIdleChannelAdapter.java
spring-integration-mail/src/test/java/org/springframework/integration/mail/ImapMailReceiverTests.java
JIRA: https://jira.spring.io/browse/INT-3499
- Suppress (log) 'null' payload error when no correlation data
- Change tests to use a dedicated template for confirms/returns
Conflicts:
spring-integration-amqp/src/test/java/org/springframework/integration/amqp/config/AmqpOutboundChannelAdapterParserTests.java
src/reference/docbook/amqp.xml
Resolved.
