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.
https://build.spring.io/browse/INT-MASTER-653
The test-case uses only 1 second to wait for the message
in the `QueueChannel`.
That isn't enough on slow environment like CI causing failure for
the current test and unexpected value in the queue for the subsequent
tests
* Fix timeouts
* Get rid of `CountDownLatch` - the same is done by the wait on queues
* Purge queue in between tests.
This way we may not have failed subsequent test, thus failure analyze
will be much easier
* Rework `testRollback()` to wait for good result after one retry over
rollback
* Remove duplicate bean definition from XML config
**Cherry-pick to 4.3.x and 4.2.x**
Conflicts:
spring-integration-core/src/test/java/org/springframework/integration/channel/TransactionSynchronizationQueueChannelTests.java
Resolved.
https://build.spring.io/browse/INT-AT42SIO-502
There is a small time window when we remove the current consumer
from the local store, but there is no a new one yet.
So, we have to check the `Set`(`Map`) size before calling its `iterator`
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4270
Initial Commit
Remove `final` modifier from certain critical framework methods that prevent CGLib proxies working.
Since Spring Boot 2.0 now uses proxyTargetClass=true by default (and has done that for
transactional proxies since 1.4), we must relax these restrictions so that CGLib can
proxy channels (which is often done to make subflows run in a transaction).
When CGLib can't override a `final` method, the fields used within those methods are uninitialized.
In the case of `AbstractMessageChannel` this causes an NPE on the unitiallized `dataTypes` field.
With `MessageHandler`, fields like `shouldTrack` are always false.
Further, methods on `IntegrationObjectSupport` - such as `getComponentName()` return null.
I have left setters and `afterPropertiesSet` (on IOS) `final` since these will typically be called
before the object is proxied.
I suspect there will be other methods we need to open up, but perhaps we should only do them on-demand.
__cherry-pick to 4.3.x__
It's difficult to subclass this mapper (e.g. to extend `toHeaders` to tweak the map)
because the factory methods for inbound and outbound mappers use private static fields
to set up the standard header mapping.
Extract that logic so that subclasses can create similar static methods and invoke the
setup code to set the standard header mapping.
Polishing: make more `DefaultHttpHeaderMapper` members available for inheritors
Conflicts:
spring-integration-http/src/main/java/org/springframework/integration/http/support/DefaultHttpHeaderMapper.java
JIRA: https://jira.spring.io/browse/INT-4259
Since DEBUG can switched off for the application, it becomes difficult
to determine the wrong configuration for the discard flow from
the scheduler thread.
* Change logging level to the `WARN` and log the full stack-trace as well
to give more information about the reason of rescheduling group for
`forceComplete`
**Cherry-pick to 4.3.x**
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/aggregator/AbstractCorrelatingMessageHandler.java
Resolved.
