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).
Jdbc Message Store always converts the correlation id
to a UUID string, even if it's already a String.
This causes reaper issues with the correlating message
handler because the reap occurs under
a different lock to normal group processing.
This change ensures the lock is properly mutually
exclusive.
* INT-1819:
INT-1819 Mail pseudo-tx support Added pseudo-tx support for Mail inbound adapters For polling adapters no changes have been made other then returning a javax.mail.Message instead of its copy so post-tx dispositions could be performed on it. For Imap IDLE adapter changes are simiar to the once present in SPCA where TX synchronization logic was added to ImapIdleChannelAdapter Couple of things to note: First IDLE receives an array of messages while Polling task receives one message which means i need to sendMessage in the Polling task in the separate thread, so for maintaining single thread semantics we have now it uses single thread executor to send Messages Renamed MSRH to TransactionalResourceHolder since we no longer use 'source' anywhere and in the case of IDLE there is no MessageSource. Its is truly a holder of attributes we want to make available for use (e.g., SpEL)
Added pseudo-tx support for Mail inbound adapters
For polling adapters no changes have been made other then returning a javax.mail.Message instead of its copy so
post-tx dispositions could be performed on it.
For Imap IDLE adapter changes are simiar to the once present in SPCA where TX synchronization logic was added to ImapIdleChannelAdapter
Couple of things to note:
First IDLE receives an array of messages while Polling task receives one message which means i need to sendMessage in the Polling task in the separate thread, so for maintaining single thread semantics we have now it uses single thread executor to send Messages
Renamed MSRH to TransactionalResourceHolder since we no longer use 'source' anywhere and in the case of IDLE there is no MessageSource. Its is truly a holder of attributes we want to make available for use (e.g., SpEL)
INT-1819 Polishing
- Change TransactionalResourceHolder to IntegrationResourceHolder
- Make messageSource available as an attribute
- Allow configuration of Executor for ImapIdle adapter
- Add parser test for TX ImapIdle adapter
- Fix bundlor config for mail
- Remove top level <transactional/> element that was added to core
- Restore 'legacy' mail attributes in TX, and add schema doc
INT-1819 Mail TX Reference Docs
Add reference documentation for mail transaction support.
INT-1819 Remove 'public abstract' from interface
Modifiers are not needed on an interface.
Currently, HTTP mappers don't know if they are inbound
or outbound. This causes problems with mapping certain
headers.
For example, on an inbound adapter, a mapped Content-Length
header should not be re-mapped to an HTTP Header during
response header mapping. However, the Content-Length
does need to be mapped on an outbound adapter response.
Introduce the notion of an exclusion list for both
request and response standard headers.
If a mapper has been configured to use standard headers,
we can detect whether the mapper is being used for inbound
or outbound mapping. We can then apply an 'exclusion' for
certain headers.
Currently, no request headers are suppressed on outbound
mappers and only the 'Content-Length' response header
is suppressed on inbound mappers.
The default mappers created via the static factory
methods use these defaults. Exposing the exclusion setters
will allow users to suppress additional headers, if
deemed necessary.
