Fixes: #9492
Issue link: https://github.com/spring-projects/spring-integration/issues/9492
Switches `MockIntegrationContextCustomizerFactory` & `SpringIntegrationTestExecutionListener`
to use `TestContextAnnotationUtils` in order to properly support
`@NestedTestConfiguration` semantics.
Adds an integration test with a base class and several
`@Nested` inner test classes to verify the various
permutations of `@SpringIntegrationTest` inherit/override
behavior when used w/ `@NestedTestConfiguration`.
**Auto-cherry-pick to `6.3.x` & `6.2.x`**
Fixes: #9455
Issue link: https://github.com/spring-projects/spring-integration/issues/9455
* Add an `IntegrationKeepAlive` infrastructure bean to initiate a long-lived non-daemon thread
to keep application alive when it cannot be kept like that for various reason, but has to.
* Expose `spring.integration.keepAlive` global property to disable an `IntegrationKeepAlive` auto-startup
* Test and document the feature
Fixes: #9507
Issue link: https://github.com/spring-projects/spring-integration/issues/9507
* Deprecate `PythonScriptExecutor` in favor of `PolyglotScriptExecutor` with a `python` as language
* Add handling for `PolyglotWrapper` return type of the script evaluation
* Rework `DeriveLanguageFromExtensionTests.testParseLanguage()` to the `@ParameterizedTest`
Fixes: #9452
Issue link: https://github.com/spring-projects/spring-integration/issues/9452
* Move the logic about `fileNameGenerator` configuration out of `AbstractZipTransformer`
since this property is not used by `UnZipTransformer` implementation
* Add more docs about `ZipTransformer` logic
Fixes: #9436
Issue link: https://github.com/spring-projects/spring-integration/issues/9436
* Expose `IndexAccessor` configuration options on the `AbstractEvaluationContextFactoryBean`
and `SpelPropertyAccessorRegistrar`
* Expose `<index-accessors>` sub-element for the `<spel-property-accessors>`
* Adjust tests
* Document the feature, including recently added `JsonIndexAccessor`
Fixes: #9428
Issue link: https://github.com/spring-projects/spring-integration/issues/9428
When `ClientManager` is used for MQTT channel adapters, a `MqttMessageDeliveredEvent`
is not emitted since callback for the `ClientManager` is not aware about `deliveryComplete`
* Use a `MqttActionListener` abstraction for the `publish` operation instead of a `deliveryComplete`
from a common callback
* Make some other refactoring into the `MqttPahoMessageHandler` and `Mqttv5PahoMessageHandler`
extracting a common logic into their `AbstractMqttMessageHandler` superclass
* Introduce an `MqttMessageNotDeliveredEvent` to be emitted from the `MqttActionListener.onFailure()` callback
* Adapt mocks in the `MqttAdapterTests` for a new code flow
* Add delivery events verification into the `ClientManagerBackToBackTests`
* Fix race condition in the `ClientManagerBackToBackTests`
Looks like the message can be consumed even before we just emit that `MqttMessageSentEvent`
The extra REST API to get commands for specific bean does not make sense.
Exactly same data can be extracted from the JSON returned by the `getCommands` REST API
Fixes: #9380
Expose a `Consumer<SshClient> sshClientConfigurer` option for the `DefaultSftpSessionFactory`
to further customize an internal `SshClient` instance.
* Use `ObjectProvider<FormattingConversionService>` instead for injection
to resolve the target bean later when we check that `spring-mvc` or `spring-webflux` is present in classpath
* Fix `control-bus-controller.adoc` for `{beanName}` attribute resolution attempt
Fixes: #9381
Currently, there is no way to know in one place what Control Bus commands are available and with what arguments
* Add `ControlBusCommandRegistry` infrastructure bean to gather control bus commands from beans and expose them for invocation
* Add `ControlBusController` to expose a `/control-bus` REST service against the mentioned `ControlBusCommandRegistry`
* Add `@EnableIntegrationManagement(loadControlBusCommands)` to be able to load all the Control Bus commands from the application context instead of on demand by default
* Deprecated existing SpEL(and Groovy)-based Control Bus functionality in favor of new, more manageable, logic
Fixes: #9291
* Modify `unlock()` method of `JdbcLock`: if the lock ownership can not be removed due to data expiration, a `ConcurrentModificationException` should be thrown.
* Modify `unlock()` method of `RedisLock`: if the lock ownership can not be removed due to data expiration, a `ConcurrentModificationException` should be thrown.
* Maintain test cases
* Document the new behavior
Fixes: #9228
* add docs
* protected constructor in ZeroMqMessageHandlerSpec, expose them via ZeroMq
* introduce ZeroMqUtils, for common Zero MQ utilities functions
* use ZeroMqUtils.bindSocket in ZeroMqMessageProducer
* refactor ZeroMqMessageHandler providing connectUrl and bindPort setters and simple constructors, following the same logic used for ZeroMqMessageProvider
* fix tests to follow the new ZeroMqMessageHandler implementation
* fix typo
* add new updates to whats-new.adoc
* address ZeroMQUtils comments
* remove connectUrl and boundPort setters, add Javadoc to new constructors
* add new DLS constructor for random port
* add since closure in ZeroMqUtils
* add DSL support methods and specific that, when not defined, the socket will be bound to a random port
Fixes: #9192
With modern drivers we don't need BLOB-specific handling anymore.
The regular `PreparedStatement.setBytes()` and `ResultSet.getBytes()`
are enough for our serialized messages
Fixes: #8898
In some cases not all retched remote files are processed, and after changing the `SessionFactory` (e.g. `RotatingServerAdvice`)
thy might not be processed on the next polling cycle
* Move `whats-new` to `changes-6.2-6.3.adoc`
* Upgrade dependency to the latest (including Gradle)
* Move Spring dependencies to based on SF-6.2
* Fix some deprecations and incompatibility
Fixes: #9001
The `ObservationPropagationChannelInterceptor` does not propagate an observation properly.
And it fully cannot when the message channel is persistent.
* Deprecate `ObservationPropagationChannelInterceptor` in favor of enabled observation on the channel
and target `MessageHandler` which is a consumer of this channel.
* Remove tests with an `ObservationPropagationChannelInterceptor`
* Mention a correct behavior in the `metrics.adoc` and `ObservationPropagationChannelInterceptor` Javadocs
**Auto-cherry-pick to `6.2.x`**
Fixes: #8631
The `ChannelPublishingJmsMessageListener` (and respective Java DSL specs)
can now be supplied with a `RetryTemplate` & `RecoveryCallback` for retying `send` & `send-and-receive` operations
in the internal gateway implementation.
The `JmsMessageHeaderErrorMessageStrategy` was introduced to have access into a raw JMS message from retry context.
The functionality is modeled after `AmqpInboundChannelAdapter`
Fixes: #8981
Sometime the simple `boolean failover` on the `MessageChannel` (default `true`)
is not enough to be sure that we can dispatch to the next handler or not.
Such a decision can be made using `ErrorMessageExceptionTypeRouter`, but that would
require an overhaul for the whole integration flow
* Introduce a simple `Predicate<Exception> failoverStrategy` into `UnicastingDispatcher`
and all its `MessageChannel` implementation consumers to allow to make a decision about next failover
according to a thrown exception from the current `MessageHandler`
* Expose `failoverStrategy` on the `DirectChannel`, `ExecutorChannel` & `PartitionedChannel`,
and add it into respective Java DSL specs
* Fix involved tests to rely on the `failoverStrategy` property from now on
* Document the new feature
Fixes: #7925
The `MessageHistory.write()` creates not only a new instance of the `MessageHistory`,
but also a new copy of the whole message.
This significantly impacts the performance when we have too many components to track
* Make `MessageHistory` as append-only container and create a new instance (plus message)
only on the first track when no prior history is present
* Change `WireTap`, `BroadcastingDispatcher`, `AbstractMessageRouter` and `AbstractMessageSplitter`
to use a new `AbstractIntegrationMessageBuilder.cloneMessageHistoryIfAny()` API for every branch a message
is produced.
Essentially, create a new message with copy of the message history to let that downstream sub-flow
have its own trace
* Modify failed unit tests for a new logic where message history header is not immutable anymore
* This also fixes an `AbstractMessageSplitter` for propagating its track into messages it emits
* * Do not clone message history header if only one consume in multi-publish
* Fix typos in docs
Fixes: #8901
Provide a convenient API `MockIntegrationContext.substituteTriggerFor(String pollingAdapterId, Trigger trigger)`
to mitigate the time span which might be provided in the original configuration
* Add `MockIntegrationContext.substituteTriggerFor(String pollingAdapterId, Trigger trigger)`
* Refactor `MockIntegrationContext` for Java 17 code style
* Change `MockIntegrationContext.beans` to `MultiValueMap` since we may replace several properties of
the same endpoint
* Modify `MockMessageSourceTests.testMockMessageSource()` to use new `substituteTriggerFor()`, too
* Add Javadoc for the `OnlyOnceTrigger`
* Document the new feature and mention it with correlation to `OnlyOnceTrigger`
Due to an antora ordering issue, the reference docs on the latest GA from
the project site throws an HTTP 404.
See spring-projects/spring-framework#32083 for more details.
* Upgrade supported dependencies to their latest versions or `alpha`, `RC`
* Migrate to `com.github.spotbugs` plugin
* Upgrade to GraalVM `23.1.1`, which includes `org.graalvm.polyglot:js` migration
* Remove `spring-integration-security` module
* Fix Debezium tests according to the latest changes in the Debezium library
* Fix deprecations and incompatibility for latest Smack and Spring AMQP
Fixes: #8806
According to RFC 9110, the `TRACE` request must not contain the body and DELETE (like GET and HEAD)
should not.
* Fix `BaseHttpInboundEndpoint` adding `TRACE` & `DELETE` to the `NON_READABLE_BODY_HTTP_METHODS` list
* Clean up typos and links in the `http/inbound.adoc`
Fixes https://github.com/spring-projects/spring-integration/issues/8797
After migration to Apache MINA we have missed to fix `DefaultSftpSessionFactory.timeout`
to be `0` by default as it states in its Javadocs and reference manual
It is `null` by default which really means an infinite wait.
* Fix `DefaultSftpSessionFactory.timeout` to be a reasonable 30 seconds by default
* Fix `setTimeout()` Javadocs and respective `session-factory.adoc`
* Propagate this `timeout` down to the `SftpClient` for its commands interactions
The `SecurityContextPropagationChannelInterceptor` has been migrated to `spring-security-messaging`.
Since it was only the class in the `spring-integration-security`, it is now fully considered
as deprecated
* Remove all the tests from `spring-integration-security`
* Modify `HttpDslTests` to demonstrate the `spring-security-messaging` in action
which has been replaced with whatever there was in `spring-integration-security`
* Remove redundant `exclude group: 'org.springframework'` for security
dependencies in `build.gradle` since all of them rely on the same SF deps
as SI
Fixes https://github.com/spring-projects/spring-integration/issues/8760
* Make `PostgresChannelMessageStoreQueryProvider` to use single `DELETE ... RETURNING` for polling statements
* Add `isUsingSingleStatementForPoll` and use it from `JdbcChannelMessageStore`
* Execute Postgres init scripts to `PostgresContainerTest`
* Code clean up
* Document the new feature
* Change the default polling trigger to 1 second
The current default trigger for the poller is 10 milliseconds fixed delay.
This is very tight policy for Microservices where we might not have too many
scheduled threads to distribute polling endpoint jobs evenly.
* Change the default trigger to 1 second to align with what Spring Boot already
claims.
Same 1 second policy is used in Spring Cloud Stream as well
* Fix language in Docs
Co-authored-by: Gary Russell <grussell@vmware.com>
---------
Co-authored-by: Gary Russell <grussell@vmware.com>
