https://build.spring.io/browse/INT-MASTER-733
The Netty tries to load `netty-transport-native-epoll` too long, more
then 10 seconds we expect in the `AbstractStompSessionManager`, therefore
we end up having `StompConnectionFailedEvent` as a first event in the
queue channel for STOMP events.
* Increase connection wait timeout to `30 secs`, like it is in many other
places in Spring
* Provide some Java 8 style refactoring for the `AbstractStompSessionManager`
* Fix `StompServerIntegrationTests` to poll events from queue until
`StompSessionConnectedEvent` any way
* Upgrade to Gradle 4.0 and `spring-io-plugin-0.0.8`
* Bump `org.sonarqube` version to `2.5` - `2.1` isn't compatible with Gradle 4.0
JIRA: https://jira.spring.io/browse/INT-4303
Don't emit ignored files in the output message payload.
Also, always preserve the timestamp when using `FileExistsMode.REPLACE_IF_MODIFIED`.
Some code style polishing
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
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**
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.
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
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
Since we don't have one more Spring AMQP 2.0 Milestone for upcoming
Spring Boot Milestone Spring Integration Milestone must be compatible
with current IO state.
* Replace `AmqpHeaders.RAW_MESSAGE` to the
`AmqpMessageHeaderErrorMessageStrategy.AMQP_RAW_MESSAGE` constant
* The `@MessageMapping` now requires `@SendTo` for replies
even if we are going to send to the default topic
* Fix assertion for exception message in the `StompInboundChannelAdapterWebSocketIntegrationTests`
* Fix `ControlBusParserTests` test to pass `Object.class` to the
`MessageConverter` since we can't use `null` there any more
* Fix `JmsOutboundGateway` for empty string for the
`replyDestinationName` since we can't pass `null` there any more
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**
JIRA: https://jira.spring.io/browse/INT-4033
Provide a mechanism to support dynamic timeouts when invoking gateway methods.
Polishing - PR Comments
* Polishing `what's new`
* Add `STOMP` to the `endpoint-summary.adoc`
* Polishing code style a bit for the changes in this fix
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`
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
spring-integration-amqp/src/test/java/org/springframework/integration/amqp/inbound/InboundEndpointTests.java
* Use `AmqpHeaders.RAW_MESSAGE` as a retry context key
* Simple polishing for Java 8 code style
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**
JIRA: https://jira.spring.io/browse/INT-4283
Filter that only passes files where a corresponding "marker" file is also present.
Implementations for file and(S)FTP.
* Polishing - PR Comments
* Missed one
JIRA: https://jira.spring.io/browse/INT-4269
* Check if `outputChannel` is `ReactiveStreamsSubscribableChannel`
to let back-pressure splitting
* Build `Flux` or `Iterator` depending in the `reactive` state
* Allow to get a size of the `iterator` if it is possible,
for example `XPathMessageSplitter`
Add tests
Fix raw type and unused import
* Add JavaDocs to the `AbstractMessageSplitter#obtainSizeIfPossible()`
* Add asserts for the `sequenceSize` populataiton in the `XPathMessageSplitter`
* Document `Stream` & `Flux` support in the splitter
Minor doc polishing
JIRA: https://jira.spring.io/browse/INT-4282
Unrecognized components were not added to `targetIntegrationComponents` causing
problems such as messge-driven components not starting.
JIRA https://jira.spring.io/browse/INT-4002
To avoid some confuses during developing target applications,
warn end-users that it is important to initialize data base before
running applications with JDBC Message Stores
