To simplify project support, it is better to let
this `5.5.x` branch to be build with Java 17
while keeping the old code style and bytecode
for Java 8 compatibility.
* Remove usage of non-stable `org.springframework.util.SocketUtils`
* Replace it with `0` for those tests where it is possible to select OS port
* Remove the mentioning of the `SocketUtils` from the `testing.adoc`
* Use `TransportConstants.DEFAULT_STOMP_PORT` for `StompServerIntegrationTests`.
We may disable this test in the future for CI if it is not going to be stable
* Introduce `Supplier<String> connectUrl` variants for `ZeroMqMessageHandler`
to let it defer connection evaluation until subscription to the socket `Mono`
in the `ZeroMqMessageHandler`.
* Move connection logic in the `ZeroMqMessageHandler` to `Lifecycle.start()`
Related to https://github.com/spring-projects/spring-framework/issues/28054
**Cherry-pick to `5.5.x`**
# Conflicts:
# spring-integration-stomp/src/test/java/org/springframework/integration/stomp/client/StompServerIntegrationTests.java
The default `TTL` in the `DefaultLockRepository` is 10 seconds which mislead us
when other client instance has just 100 millis.
So, not-adjusted client spins for expired lock wastefully leading to the
synchronization barriers to fail
**Cherry-pick to `5.4.x`**
Fixes https://github.com/spring-projects/spring-integration/issues/3716
If the `redisMessageListenerContainer` is starting, waiting for it to complete without doing `subscribeUnlock()`
* Introduce `isRunningRedisMessageListenerContainer` state since the `running` in the `RedisMessageListenerContainer` is set in the beginning of the `start()` misleading on the concurrent calls to the `RedisLockRegistry`
**Cherry-pick to `5.5.x`**
Fixes https://github.com/spring-projects/spring-integration/issues/3711
The `contentType` header may come with parameter in its media type.
* Fix `AbstractHttpRequestExecutingMessageHandler` to use `equalsTypeAndSubtype()`
ignoring params
* Some other code clean up in the `AbstractHttpRequestExecutingMessageHandler`
* Ensure in the `HttpRequestExecutingMessageHandlerTests.simpleStringKeyStringValueFormData()`
that provided `contentType` header is handled properly
* Fix `HttpProxyScenarioTests.testHttpMultipartProxyScenario()` for mislead multi-part form
handling
**Cherry-pick to `5.5.x`**
Resolves https://github.com/spring-projects/spring-integration/issues/3713https://github.com/spring-projects/spring-integration/issues/3326 added support
for multiple `TcpSenders`. However, when connections are intercepted, the sender
list was not properly chained through the interceptors.
- override `registerSenders` and properly capture the real senders in the last
interceptor and intermediate interceptors
- this ensures that `addNewConnection` is called on each interceptor
- when removing dead connections, use the connection sender list insted of the
factory's raw sender list; detect if the connection is an interceptor and
call its remove method instead.
**cherry-pick to 5.5.x**
Fixes https://github.com/spring-projects/spring-integration/issues/3705
Closing/destroying `ChannelOutputStream` object does not close the selector therefore it retains redundant pipes/FD that cen be seen using lsof command or ls /proc/
* Close `TcpNioConnection.ChannelOutputStream.selector` in the `ChannelOutputStream`
* Close `TcpNioConnection.ChannelOutputStream` when connection is closed
* Code style clean up
**Cherry-pick to `5.3.x` & `5.4.x`**
Fixes https://github.com/spring-projects/spring-integration/issues/3700
Fixed a case where lock acquisition attempt was abandoned earlier than expected time.
If a vm uses `tryLock()` and another vm unlock it, it will wake up with an unlock message and try to acquire the lock,
but if it fails(the other vm obtain lock), vm will return false.
Turns out Eclipse Kotlin plugin is not perfect at the moment,
and it causes some code parsing problems in the editor.
* Move Kotlin annotation to Java to mitigate normal source code flow:
Java to Kotlin, not opposite
Resolves https://github.com/spring-projects/spring-integration/issues/3701
Ensure `TcpSender.removeDeadConnection` is always called, for example when
intercepted and closed via `factory.closeConnectionId` or when closed
connections are harvested from the `connections` map.
**Cherry-pick to 5.4.x, 5.3.x**
* Add missed factories, introduced recently into Java DSL
* Add `@IntegrationDsl` - a Kotlin-specific `@DslMarker` annotation
to mark classes (including Java) which are used in Kotlin DSL as a builder pattern.
This way the scope of the builder is honored and IDE does not suggest functions from
higher lambda for builder
* Fix `element-list` reference for Dokka plugin configuration from the respective module
* GH-3694: Resolve circular dep in PublisherAnnBPP
Fixes https://github.com/spring-projects/spring-integration/issues/3694
* Move check for `PublisherAnnotationBeanPostProcessor` bean into the
`SmartInitializingSingleton.afterSingletonsInstantiated()` to break a circular dependency revealed
in the `InitializingBean.afterPropertiesSet()`
* * Fix unused import
Fixes https://github.com/spring-projects/spring-integration/issues/3688
The `WebServiceTemplate` is populated with some defaults from its ctor.
We should rely on the target default template values as much as possible
and don't override them to `null` if end-user doesn't ask about that explicitly
* Fix `BaseWsOutboundGatewaySpec` extensions to populate values to the target gateway
only if they are not null - therefore provided by end-user
* If end-user wants them explicitly `null`, it is better to do that via
externally configured template.
See overloaded variants for DSL: `Ws.marshallingOutboundGateway(WebServiceTemplate)`
and `Ws.simpleOutboundGateway(WebServiceTemplate)`
**Cherry-pick to `5.4.x` & `5.3.x`**
Fixes https://github.com/spring-projects/spring-integration/issues/3683
If a transaction is already active while `JdbcLockRegistry` uses
`DefaultLockRepository` to acquire/release a lock, the repository
must execute SQL queries in a separate transaction to prevent
problems with blocking, deadlocking etc.
It also allows to properly follow transaction isolation level that
is set on some methods of `DefaultLockRepository`.
Previously all methods of DefaultLockRepository supported the current
transaction if there are any. Now all methods will always create new
transaction on each call.
* Change tests to be more unit-ish
* Change `@since` for the `DefaultLockRepositoryTests` to `5.3.10`
**Cherry-pick to `5.4.x` & `5.3.x`**
Rework the logic around `ManagedList` in the `DefaultConfiguringBeanFactoryPostProcessor`
when it registers a `IntegrationContextUtils.MESSAGE_HANDLER_FACTORY_BEAN_NAME` and
`IntegrationContextUtils.LIST_MESSAGE_HANDLER_FACTORY_BEAN_NAME` into a dedicated
`MessageHandlerMethodFactoryCreatingFactoryBean` with pure Java code instead of
`BeanDefinition` burden
* Deprecate `IntegrationContextUtils.DISPOSABLES_BEAN_NAME` constant for
already removed internal bean
* Align JVM args for Gradle with Java 17 on the `6.0` branch
* Remove `Disposables` since it is a package protected therefore could not be used outside
* Remove the logic relevant ot the `Disposables` in the `MessagingAnnotationPostProcessor` logic
* Replace a `registerSingleton()` and `initializeBean()` with the proper `registerBeanDefinition()`
and `getBean()` usage.
This way bean are going to be destroyed properly
* Remove `MessagingAnnotationPostProcessorChannelCreationTests` since its mocking logic is too vague
and really covered with many other real tests.
The `MessagingAnnotationPostProcessor` registers a `Disposables` unconditionally.
The `afterPropertiesSet()` maybe called several times, so `IntegrationContextUtils.DISPOSABLES_BEAN_NAME`
registration has to be idempotent.
* Add `if (!this.beanFactory.containsBeanDefinition(IntegrationContextUtils.DISPOSABLES_BEAN_NAME))`
before trying to register `Disposables` bean
