Fix JdbcMessageStoreChannelTests.testSendAndActivateWithRollback as well as others by changing poller interval.
Poller was polling too quickly, so even the slightest delay before assertion would result in another Message in the Service.messages thus the intermittent assertion error.
INT-2280 Polishing
Don't add retries to message list.
* make `AmqpOutboundEndpoint` 'exchangeName' & 'routingKey' **null** by default
* some polishing for `AmqpOutboundEndpoint`
* verification tests for parameters of `com.rabbitmq.client.Channel#basicPublish`
JIRA: https://jira.springsource.org/browse/INT-2773
INT-2773 Polishing - Allow Override to ""
Previously, there was no way to revert to the previous
behavior by specifying an empty string for the attribute(s).
Add test to verify setting attributes to "" overrides template.
Ensured that bindings of the resource only happen if TransactionSynchronizationFactory is not null
Add documentation describing the expectation for the unbinding of the resource.
INT-2777 Polishing
Don't set up holder if it's not used.
Doc fixes.
Retry Advice (ErrorMessageSendingRecoverer) tried to send a message
with a null payload when the RetryPolicy allowed zero attempts.
Create a MessageHandlingException with the failedMessage, when
no attempts were made to call the handler.
INT-2753 - Add CONTRIBUTING.md Copied from the Contributor Guidelines wiki document [1] in order to take advantage of GitHub's new integrated support for displaying a link to contributor guidelines when issuing a pull request [2].
# By Oleg Zhurakousky
* olegz-INT-2774/75:
INT-2774/75 RedisCollectionPopulatingMessageHandler fix * Added support for 'channel' attribute for RedisStore outbound adapter * Fixed logic in RedisCollectionPopulatingMessageHandler to ensure that RedisHeaders.ZSET_INCREMENT_SCORE can be passed as Boolean true/false as well as String true/false. The current solution is based on relyiong oin ConversionService registered with SpEL Context (see RedisCollectionPopulatingMessageHandler.extractZsetIncrementHeader method). This way other types could be supported without introducing any code changes.
* Added support for 'channel' attribute for RedisStore outbound adapter
* Fixed logic in RedisCollectionPopulatingMessageHandler to ensure that RedisHeaders.ZSET_INCREMENT_SCORE can be passed as Boolean true/false as well as String true/false. The current solution is based on relyiong oin ConversionService registered with SpEL Context (see RedisCollectionPopulatingMessageHandler.extractZsetIncrementHeader method). This way other types could be supported without introducing any code changes.
The ExpressionEvaluatingMessageHandlerAdvice now sends an
AdviceMessage which has a payload of the original message, and
a property 'inputMessage' referencing the message that was
sent to the advised handler.
INT-2763 Expression Advice Reference Doc Update
Update to reflect the new behavior.
Adding a header redis_zset_overwrite modifies behavior to
overwrite instead of incrementing score.
Remove underscores from redis headers.
INT-2761,2762 Polished ZSet operations
polished ZSet logic related to zset increment score
changed Redis class names from RedisCollections* to RedisCollection*
INT-2761,2762 polishing
While Spring Framework 3.1 is recommended for Spring
Integration 2.2, it continues to support Spring 3.0.
Change build.gradle to use 3.0.7 as the minimum instead
of 3.1.1.
INT-2683 Tests
Expanded JMS Gateway Tests
INT-2683 First commit
Listener Container Option for Replies
INT-2683 Remove no correlation-key Option
INT-2863 Support DestName and Temp Dest
INT-2683 Add back Support No CorrelationKey
INT-2683 Fix Tests
INT-2683 Polishing
Fallback if no correlationKey and fixed reply queue.
INT-2683 Polishing
Change from SMLC to DMLC
INT-2683 Polishing
Since we changed to DMLC, we can now remove the check for
SingleConnectionFactory.
INT-2683 <reply-listener/> Namespace Support
Add <reply-listener/> subelement to JMS Outbound Gateway.
Race condition for deletion after poll.
Also, during development, the batch flag was
flipped from default true to false.
This resulted in two tests for row deletion.
Changed the first test to use batch deletion.
Fix removeMessageGroup logic to ensure it also executes
delete on the join table so there are no dangling
join rows.
Add defensive logic to the getMessageGroup method
to ensure it no longer throws an exception IF the scenario
fixed with the previous comment still re-appears
(and it can if MGS is not executed under TX).
