Fixesspring-projects/spring-integration#2213
JIRA: https://jira.spring.io/browse/INT-4123
Fully different `MessageStore`s can be configured for the same shared
Key-Value data-base.
Since the retrieval logic is based on the keys, that may cause the
unexpected messages expiration via `MessageGroupStoreReaper`.
* To distinguish store instances on the shared store add `prefix`
option to the `AbstractKeyValueMessageStore`
* Deprecate the `GemfireMessageStore` `Cache`-based configuration - `setIgnoreJta()` and `afterPropertiesSet()`.
The `GemfireMessageStore` relies only on an externally configured `Region`.
**Cherry-pick to 4.3.x**
Doc Polishing
# Conflicts:
# spring-integration-core/src/main/java/org/springframework/integration/store/AbstractKeyValueMessageStore.java
# spring-integration-gemfire/src/main/java/org/springframework/integration/gemfire/store/GemfireMessageStore.java
# spring-integration-redis/src/main/java/org/springframework/integration/redis/store/RedisMessageStore.java
* Fix tests `GemfireMessageStore` tests conflicts
JIRA: https://jira.spring.io/browse/INT-4340
* Roster is now disabled on login as well
* Fixed tagging and formatting issues
* Checkstyle and documented the changed behaviour as well
Polishing: rely on the `AbstractFactoryBean.getObject()`
**Cherry-pick to 4.3.x**
* Upgrade to SF-4.3.11 and Jackson-2.8.10
JIRA: https://jira.spring.io/browse/INT-4342
Use similar code to Spring AMQP to add white list support for Integration's
use of the `DeserializingMessageConverter`; introduce the `WhiteListDeserializingMessageConverter`.
Polishing
Missed this change in PR.
Fix XSD attribute
# Conflicts:
# spring-integration-core/src/main/java/org/springframework/integration/dsl/Transformers.java
# spring-integration-core/src/test/java/org/springframework/integration/config/xml/PayloadDeserializingTransformerParserTests.java
# spring-integration-core/src/test/java/org/springframework/integration/dsl/flows/IntegrationFlowTests.java
# spring-integration-jdbc/src/main/java/org/springframework/integration/jdbc/store/JdbcChannelMessageStore.java
# spring-integration-jdbc/src/main/java/org/springframework/integration/jdbc/store/channel/MessageRowMapper.java
# spring-integration-mongodb/src/main/java/org/springframework/integration/mongodb/store/MongoDbMessageStore.java
# spring-integration-mongodb/src/main/java/org/springframework/integration/mongodb/support/BinaryToMessageConverter.java
# spring-integration-mongodb/src/main/java/org/springframework/integration/mongodb/support/MongoDbMessageBytesConverter.java
JIRA: https://jira.spring.io/browse/INT-4341Fixesspring-projects/spring-integration#2228
Add to the `RedisQueueInboundGateway` and `RedisQueueMessageDrivenEndpoint`support
for the `receiveTimeout` of 0 and block indefinitely
Added some simple tests to check if the receive timeout can be set to 0
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4336
Don't add "hidden" unreachable methods to the map in the `GatewayProxyFactoryBean`.
The methods can never be executed and may not have all expected properties; they
should not appear in the graph at all since they are unreachable.
Also add defensive coding to the `IntegrationGraphServer` to avoid NPEs when unexpected
conditions arise.
# Conflicts:
# spring-integration-core/src/test/java/org/springframework/integration/dsl/reactivestreams/ReactiveStreamsTests.java
# spring-integration-core/src/test/java/org/springframework/integration/gateway/GatewayProxyFactoryBeanTests.java
JIRA: https://jira.spring.io/browse/INT-4326
To let to disable autoStartup for particular endpoint bean globally,
in one place, add `spring.integration.endpoints.noAutoStartup`
to the `spring.integration.properties`
So, now all the `AbstractEndpoint` checks that property for matching its
bean name to configure `autoStartup` property to `false`
**Cherry-pick to 4.3.x**
Conflicts:
spring-integration-core/src/main/resources/META-INF/spring.integration.default.properties
spring-integration-core/src/test/resources/META-INF/spring.integration.properties
src/reference/asciidoc/configuration.adoc
Resolved.
Fixesspring-projects/spring-integration#2217
The `MutableMessageHeaders` delegates provided headers to the super
which just generates fresh `ID` & `TIMESTAMP` headers ignoring provided.
* Add explicit `ID` & `TIMESTAMP` headers population in the
`MessageJacksonDeserializer` after creation `MutableMessageHeaders`.
We can't apply the fix for the `MutableMessageHeaders` like it is in
the `master` because it would be a breaking change
JIRA: https://jira.spring.io/browse/INT-4328
Add support for sending `ErrorMessage`s to the return and nack channels.
**cherry-pick to 4.3.x, but change default EMS to null (will require minor adjustment to test - set the EMS in `adapterWithReturnsAndErrorMessageStrategy`)**
# Conflicts:
# spring-integration-amqp/src/main/java/org/springframework/integration/amqp/outbound/AbstractAmqpOutboundEndpoint.java
# spring-integration-amqp/src/main/java/org/springframework/integration/amqp/support/AmqpMessageHeaderErrorMessageStrategy.java
# spring-integration-amqp/src/test/java/org/springframework/integration/amqp/outbound/AmqpOutboundEndpointTests.java
# spring-integration-amqp/src/test/java/org/springframework/integration/amqp/outbound/AsyncAmqpGatewayTests.java
# spring-integration-core/src/main/java/org/springframework/integration/support/DefaultErrorMessageStrategy.java
JIRA: https://jira.spring.io/browse/INT-4327
To avoid reflection and annotation processing overhead on the bean classes
when we deal with non-singleton beans and there is really no any
messaging on the bean class, store bean classes to the local cache to skip
them in the future when `BPP` is applied for request/prototype beans
* Simple code style polishing
**Cherry-pick to 4.3.x**
(cherry picked from commit 9f4f07bcfd)
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/config/annotation/MessagingAnnotationPostProcessor.java
JIRA: https://jira.spring.io/browse/INT-4324
The `preserve-timestamp` attribute for the
`<int-file:outbound-channel-adapter>` has been missed for parsing in
the `FileWritingMessageHandlerBeanDefinitionBuilder` and propagation
in the `FileWritingMessageHandlerFactoryBean`
**Cherry-pick to 4.3.x**
Conflicts:
spring-integration-file/src/main/java/org/springframework/integration/file/config/FileWritingMessageHandlerBeanDefinitionBuilder.java
spring-integration-file/src/main/java/org/springframework/integration/file/config/FileWritingMessageHandlerFactoryBean.java
spring-integration-file/src/test/java/org/springframework/integration/file/config/FileOutboundChannelAdapterParserTests-context.xml
spring-integration-file/src/test/java/org/springframework/integration/file/config/FileOutboundChannelAdapterParserTests.java
Resolved.
https://build.spring.io/browse/INT-AT42SIO-595/
To avoid clashes with other parallel builds on CI for different versions
on the same shared Redis make a testing `groupId` as unique using
`UUID.randomUUID()`
**Cherry-pick to 4.3.x & 4.2.x**
JIRA: https://jira.spring.io/browse/INT-4325
When channel adapter is defined without `id` attribute, the
`JpaInboundChannelAdapterParser` generates the name for class which
bean is never registered, therefore all the `JpaExecutor`s are registered
with the same bean name and afterward all the `JpaPollingChannelAdapter`
without `id` share the same `JpaExecutor`
* Generate bean name based on the `SourcePollingChannelAdapterFactoryBean`
which is used eventually for real bean registration
* Add test config for several channel adapters without `id`
* Optimize the `JpaInboundChannelAdapterParserTests` to start
the context only once during test class initialization
**Cherry-pick to 4.3.x**
Fixesspring-cloud/spring-cloud-stream#983
When the `AbstractMessageChannel.getFullChannelName()` is called
before the full bean initialization, we don't have the proper name any
more lately - that is only `unknown.channel.name`
* Reset `fullChannelName` property to `null` in the end of `onInit()`,
so the next `getFullChannelName()` will build the proper component name
**Cherry-pick to 4.3.x**
(cherry picked from commit 5a25993)
JIRA: https://jira.spring.io/browse/INT-4247
* Fix `JdbcLockRegistryLeaderInitiatorTests` race condition to assert
the `initiator1` is elected eventually after yielding when the
`initiator2` is stopped
* Check for `null` package in the `JacksonJsonUtils`.
Also don't call `this.delegate.typeFromId()` the second time
* Increase wait timeout in the `QueueChannelTests`
* Check `ZookeeperMetadataStore.addListener()` for `null`
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4311
* Added `QueryTimeoutException` to retry handling in the `JdbcLockRegistry`
Polishing
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4305
The `File.renameTo()` operation may fail, therefore the content of the
local file isn't changed, but since we change `setLastModified()` anyway,
this file might be eligible for local polling.
So, we end up with the same content from local file in a new message,
meanwhile we expect a new content from the remote file
* Check the `File.renameTo()` result and attempt to `delete()`
for existing local file
* When file isn't renames remove the remote file from the `filter` to let
it be transferred one more time on the next poll.
The local file might be opened for processing, so this way we postpone a fresh
remote file for the future poll rounds
* Modify `copyFileToLocalDirectory()` to return `boolean` to reflect the fact of copy.
This way we check the real number of transferred files
**Cherry-pick to 4.3.x**
Do not transfer remote file if we can't remove local one
Polishing Log Messages
Conflicts:
spring-integration-file/src/main/java/org/springframework/integration/file/remote/synchronizer/AbstractInboundFileSynchronizer.java
spring-integration-file/src/test/java/org/springframework/integration/file/remote/synchronizer/AbstractRemoteFileSynchronizerTests.java
spring-integration-ftp/src/test/java/org/springframework/integration/ftp/dsl/FtpTests.java
JIRA: https://jira.spring.io/browse/INT-4298
Used to indicate components that can propagate headers; allows suppression.
Move Interface to AbstractMessageProducingHandler
Add Docs
* Fix typo in doc
(cherry picked from commit 42dd05d)
JIRA: https://jira.spring.io/browse/INT-4271
The `Flusher.run()` is `synchronized` on the `FWMH`; a `stop()` while it's running will interrupt the task
which could cause a state to be removed without a flush actually happening (interrupt
on lock acquisition).
- synchronize `stop()` so it won't interrupt a running flusher
- detect an interrupt in the flusher and stop flushing
**Cherry-pick to 4.3.x**
(cherry picked from commit a38bf60)
JIRA: https://jira.spring.io/browse/INT-4296
The `FileState.close()` method correctly acquires the lock to prevent closing while
writing. However, with a short flush interval, the close could occur between state
creation and the write operation acquiring the lock.
Move the state creation to within the scope of the lock acquired by the writer.
(cherry picked from commit 404c2c5)
JIRA: https://jira.spring.io/browse/INT-4284
To inform end-user that he/she can't override `id` and `timestamp` headers
throw a `BeanInitializationException` from the `gateway`, `header-enricher`,
`enricher` and `header-filter` configuration when `id` and `timestamp` are
explicitly provided
(cherry picked from commit 4a47a7c)
JIRA: https://jira.spring.io/browse/INT-4290
See CVE-2017-4995
To disallow deserialization of unknown classes,
the `JacksonJsonUtils#messagingAwareMapper()` can now be supplied
with the `trustedPackages`.
The default list is:
```
java.util
java.lang
org.springframework.messaging.support
org.springframework.integration.support
org.springframework.integration.message
org.springframework.integration.store
```
Can be configured with `*` (asterisk) with meaning trust all
**Cherry-pick to 4.3.x**
Polishing according PR comments
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/store/AbstractKeyValueMessageStore.java
Resolved.
Relates to spring-cloud/spring-cloud-stream#913
and 914094e51d
Also see https://github.com/spring-projects/spring-integration-kafka/pull/163
The `RetryTemplate` and `errorChannel` are mutually exclusive options:
```
Assert.state(getErrorChannel() == null, "Cannot have an 'errorChannel' property when a 'RetryTemplate' is "
+ "provided; use an 'ErrorMessageSendingRecoverer' in the 'recoveryCallback' property to "
+ "send an error message when retries are exhausted");
```
Therefore we don't have any error handling functionality if there is a retry but no `RecoveryCallback`.
So, don't add `RetryContext` to `ThreadLocal<AttributeAccessor>` if we don't have `RecoveryCallback` provided,
because that value is out of use then.
To make code more logical perform `attributesHolder.remove()` only for the non-retryable branch.
With that refactoring the missed `attributesHolder.remove()` has been observed in the `AmqpInboundGateway`
Add `attributesHolder.remove()` to the `RetryListener.close()` for retryable branch
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4288
- Add `AbstractMessageProducingHandler.addNotPropagatedHeaders()`
so that new headers can be added without overriding existing ones.
- Add `AbstractMessageProducingHandler.getNotPropagatedHeaders()`
so that existing excluded headers can be consulted.
* Polishing JavaDocs and imports order
**Cherry-pick to 4.3.x**
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/handler/AbstractMessageProducingHandler.java
spring-integration-core/src/test/java/org/springframework/integration/handler/AbstractReplyProducingMessageHandlerTests.java
See: spring-cloud/spring-cloud-stream#913
To make compatibility with Spring AMQP 2.0 `AmqpHeaders.RAW_MESSAGE`
rename `AmqpMessageHeaderErrorMessageStrategy.AMQP_MESSAGE` constant
to the `AMQP_RAW_MESSAGE` and therefore its value to the
`AmqpHeaders.PREFIX + "raw_message"`
See c10092d0c5
JIRA: https://jira.spring.io/browse/INT-4256
Also fix the JMS endpoint to use the `MessagingTemplate` instead of sending to the
error channel directly (ignored the send result).
Missing commit
Polishing - PR Comments
* Some additional polishing: remove extra `ifs`; make internal
classes `protected` for possible inheritors
Conflicts:
spring-integration-amqp/src/main/java/org/springframework/integration/amqp/inbound/AmqpInboundChannelAdapter.java
spring-integration-amqp/src/main/java/org/springframework/integration/amqp/inbound/AmqpInboundGateway.java
AMQP: Add Support for SCSt Error Handling
See: https://github.com/spring-cloud/spring-cloud-stream/issues/913
Add retry within `onMessage` so we have access to the converted message
as well as the original spring-amqp message, which is added to the
`ErrorMessage` as a header.
Similar to the work in spring-integration-kafka.
* Polishing JavaDocs
* Rename `AmqpMessageHeaderErrorMessageStrategy.AMQP_RAW_DATA`
to `AmqpMessageHeaderErrorMessageStrategy.AMQP_MESSAGE`
JIRA: https://jira.spring.io/browse/INT-4284
Add `INFO` into the `MessageBuilder#copyHeadersIfAbsent()` when end-user
tries to populate headers which are `readOnly`
We can't throw exception on the matter since can modify `readOnlyHeaders`
and that would force end-user to add `header-filter` logic to the application.
* Document `readOnly` headers in the `message.adoc`
**Cherry-pick 4.3.x**
Conflicts:
spring-integration-core/src/test/java/org/springframework/integration/gateway/GatewayInterfaceTests.java
Resolved.
gatewayIntegrationTest() was stealing integrationTest()'s message.
Shutdown its executor and wait for the shutdown.
Also add a meaningful toString() to TcpConnectionSupport.
JIRA: https://jira.spring.io/browse/INT-4276
The `readOnlyHeaders` integration property allows suppression of certain headers
globally.
Add support for suppressing propagation on individual message handlers.
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/handler/support/CollectionArgumentResolver.java
spring-integration-core/src/test/java/org/springframework/integration/handler/AbstractReplyProducingMessageHandlerTests.java
JIRA: https://jira.spring.io/browse/INT-4272
- Honor read only header configuration when building from an unchanged message
- Support adding read only headers to the message builder factory
* Move `IntegrationMessageHeaderAccessor.containsReadOnly()` to the
`MessageBuilder` to avoid confusing
**Cherry-pick to 4.3.x**
Since the classes load their imports explicitly we can't use them for
classes which provides utilities to check classpath
* Move imports to fully qualified names in the target utility method
**Cherry-pick to 4.3.x**
Move `JacksonJsonUtils.isPresent` methods to separate `JacksonPresent` class
Polishing
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/support/converter/ConfigurableCompositeMessageConverter.java
Resolved.
JIRA: https://jira.spring.io/browse/INT-4267Fixes: spring-projects/spring-integration#2110
The documentation clearly point that we can simply use JSON (de)serialization
with the `RedisMessageStore`, but actually it isn't so easy
* Fix `MessageGroupMetadata`, `MessageHolder`, `MessageMetadata` for Jackson
deserialization compatibility
* Add `MessageHeaders`-based ctor to the `AdviceMessage`
* Add `MessageHeadersJacksonSerializer` to serialize `MessageHeaders`
to the `HashMap` for easier deserialization afterwards
* Add deserializer implementations for all `Message` types
* Add convenient `JsonObjectMapperProvider#jacksonMessageAwareMapper()`
factory method to build `ObjectMapper` supplied with mentioned above
(de)serializers
**Cherry-pick to 4.3.10 without `MessageHolder` and `MessageMetadata`**
Address PR comments and document the feature
Doc Polishing
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/store/MessageHolder.java
spring-integration-core/src/main/java/org/springframework/integration/store/MessageMetadata.java
Resolved.
