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.
JIRA: https://jira.spring.io/browse/INT-4248
Some methods in `RedisLockRegistry` is planed for removal in `5.0` because of
new architecture.
Therefore mark them `@Deprecated` in `4.3.x`
JIRA: https://jira.spring.io/browse/INT-4262
Since `IF EXISTS` doesn't exist for `DROP INDEX` command and even more
this command isn't necessary when we fully drop the table, we don't need it
as a separate command.
`DROP TABLE IF EXISTS` is fully sufficient for schema recreation requirements
* Add `NODROPINDEX` variable for VPP engine to let it do not add `DROP INDEX` command
* Fix `channel/schema-mysql.sql` for proper INDEX names
JIRA: https://jira.spring.io/browse/INT-4257
So that subclasses can also generate error message for conditions such
as message conversion errors.
Polishing - PR Comments
Fix JMS buildErrorMessage Override
Update Copyrights
(cherry picked from commit c665405)
JIRA: https://jira.spring.io/browse/INT-4257
To make a target `ErrorMessage` customizable introduce
`ErrorMessagePublishingRecoveryCallback` and
`ErrorMessageStrategy` to inject
**Cherry-pick to 4.3.x**
Fix `ErrorMessagePublishingRecoveryCallback` generic type for
`RequestHandlerRetryAdvice` compatibility
Polishing
- Support publishing when no retry context is available
- Use a constant for the message context key
Add EnhancedErrorMessage
- contains input message at time of error message generation
- make the default RecovererErrorMessageStrategy public and extensible
Fix `RetryAdviceParserTests` for new `RecoveryCallback` architecture
Rename to `ErrorMessagePublisher`
Decouple ErrorMessagePublisher from Retry
Refactoring for better purpose reflection and JavaDocs
Use `ErrorMessageStrategy` in message producers.
Add JavaDocs to the `DefaultErrorMessageStrategy`
Deprecate EnhancedErrorMessage
Minor Polish for Subclass Use
- make setters final
- allow subclasses to supply the AttributeAccessor
Fix Tests
JIRA: https://jira.spring.io/browse/INT-4248
The `RedisLockRegistry` doesn't update store for `expire` property on the
subsequent lock interaction.
Only `RedisLockRegistry.obtain()` lets us to know if we expired already or not
To minimize the time window between `lock` and `expire` facts, move `obtain()`
function in the `LockRegistryLeaderInitiator` close to `Lock` usage.
JIRA: https://jira.spring.io/browse/INT-4254
The `LockRegistryLeaderInitiator#LeaderSelector` unconditional calls
`unlock()` in the `finally` block when the `Lock` might not be locked.
Another problem that `running = true` is set after submitting `LeaderSelector` task.
That might bring the problem that `LeaderSelector` won't be selected because of
`this.running` race condition
* Move `this.running = true` before submitting `LeaderSelector` task
* Move `unlock()` into the `if (this.locked)` condition
**Cherry-pick to 4.3.x**
Conflicts:
spring-integration-core/src/test/java/org/springframework/integration/support/leader/LockRegistryLeaderInitiatorTests.java
Resolved.
JIRA: https://jira.spring.io/browse/INT-2625
Since `jdbcOperations` is mandatory property of the `JdbcMessageStore`,
make it as constructor arg to encourage users always specify `DataSource`
or `JdbcOperations`.
With that we don't need `afterPropertiesSet()` any more
https://build.spring.io/browse/INT-FATS5IC-129/
Since leader selection is done on background thread in the
`LockRegistryLeaderInitiatorTests`, there is no guarantee that
after `Thread.sleep(100)` the lock will be obtained and leader state is
changed.
* Waiting for the `granted` `CountDownLatch` is much robust condition
(cherry picked from commit d5c633d)
JIRA: https://jira.spring.io/browse/INT-4250
When retrieving the mean from `ExponentialMovingAverageRate` or
`ExponentialMovingAverageRatio` via `getStatistics()` the mean did not
decay over time.
The mean did decay when using `getMean()`.
This was caused by the statistics performance refactoring.
(cherry picked from commit fac04ae)
