The `MappingMongoConverter` now used different path when it
iterates documents form conversion from a DB cursor
* Fix `MongoDbMessageStore.MessageReadingMongoConverter` to override
a `read(TypeInformation<S>, Bson)` method to convert a `MessageWrapper` properly
* Upgrade to the latest MongoDb driver
Fixes https://github.com/spring-projects/spring-integration/issues/2708
There are some requests to use the same service method for different input channels
* Make all the messaging annotations as `@Repeatable` with their
respective container annotations
* Modify `MessagingAnnotationPostProcessor` logic to deal with the mentioned repeatable
requirements
* GH-3733 Configure TxManager for DefLockRepository
Fixes https://github.com/spring-projects/spring-integration/issues/3733
The `@Transactional` resolves a primary `TransactionManager` bean
from the application context which might not be sufficient for all
the use-case.
To make it work with the custom (or specific) `TransactionManager`
we have to extend a `DefaultLockRepository` and override all those
`@Transactional` method
* Change the logic of the `DefaultLockRepository` from `@Transactional`
to the `TransactionTemplate` and use provided `TransactionManager`
or resolve one from the application context
* Adjust tests to use explicit `TransactionManager` and call
`afterSingletonsInstantiated()` to initialize a default `TransactionTemplate`
* Mention the change in the docs
* * Extracted all the `TransactionTemplate`s to the properties for caching
* Add `BeanInitializationException` for no-unique `PlatformTransactionManager`
bean in the `afterSingletonsInstantiated()`
* Fix language in the exception message
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
Fixes https://github.com/spring-projects/spring-integration/issues/3765
The `DefaultMethodInvokingMethodInterceptor` has several strategies
for `default` method invocations in the messaging gateway.
One of them is based on the `Lookup` constructor which causes
a `WARNING: An illegal reflective access operation has occurred`.
This can be done lazily when there is no `MethodHandles.privateLookupIn`
in Java version used for the project.
* Fix `OPEN` enum value for the `Constructor<Lookup>` to be resolved in
a lazy manner via `Supplier` and `boolean` flag
**Cherry-pick to `5.5.x`**
Fixes https://github.com/spring-projects/spring-integration/issues/3615
The `log()` operator for Java DSL in the end of flow causes a confusion
for its different behavior and, therefore, inconsistency with expectations
* Populate a `bridge()` in the end of flow instead of `nullChannel` when
the current component is `WireTapSpec` (relevant to `wireTap()` and `log()`)
* Deprecate a `logAndReply()` operator since its behavior is now included into the `log()` in the end if flow
* Fix tests to use just `log()` in the end from now on
* Fix `dsl.adoc` for the new `log()` behaviour in the end of flow
The `BaseHttpInboundEndpoint` has a `JAXB_PRESENT` variable
to check before including `Jaxb2RootElementHttpMessageConverter`
which has to do that against `jakarta.xml.bind.Binder` class from Jakarta EE
Fixes https://github.com/spring-projects/spring-integration/issues/3734
The `MessageHistory` is not in the trusted packages of the `DefaultKafkaHeaderMapper`
therefore it fails when `MessageHistory.read()` is performed.
* Configure default `DefaultKafkaHeaderMapper` in the `SubscribableKafkaChannel`,
`KafkaInboundGateway`, `KafkaMessageDrivenChannelAdapter` and `KafkaMessageSource`
to also trust packages exposed via `JacksonJsonUtils.DEFAULT_TRUSTED_PACKAGES`
which include a `MessageHistory`, too.
* Verify in some integration Kafka tests to be sure that `MessageHistory` is
deserialized properly in the transferred headers
* Rework some tests to use `@EmbeddedKafka` instead of `@BeforeAll/@AfterAll`
**Cherry-pick to `5.5.x`**
Fixes https://github.com/spring-projects/spring-integration/issues/3735
The `FeedEntryMessageSource` adds an url to the provided `metadataKey`
making it incompatible when we provide a `Resource`-based configuration.
* Remove adding of the url to the `metadataKey` making it rely only
on the provided value
* Remove internal `Comparator` for entries in favor of `Comparator.comparing()`
feature
* Improve some internal logic of the `PropertiesPersistingMetadataStore`
when it emits a false warning: cannot create dirs, but they are present
* Improve `feed.adoc`
* Add documentation for GraphQL support
* * Fix to the latest Spring for GraphQL
* Mention in the doc an `ExecutionGraphQlRequest` as a request message payload
Fixes https://github.com/spring-projects/spring-integration/issues/3732
The `Mqttv5PahoMessageDrivenChannelAdapter` unconditionally tries to (un)subscribe
to/from topics when the `mqqtClient` might not be initialized yet.
* Add `mqqtClient` initialization check before adding or removing topic.
Re-align logic with the `MqttPahoMessageDrivenChannelAdapter`
**Cherry-pick to `5.5.x`**
The `Flux.takeWhile()` only works if there is data in the `Publisher`
to consume.
We still need to be able to cancel subscription and stop producing even if
there is no data at the moment.
* Change `takeWhile()` to the `doOnSubscribe()` and store `subscription`
in the `volatile` property of the `MessageProducerSupport`
* Cancel such a subscription in the `doStop()` impl
* Propagate `doStop()` to super in the `ZeroMqMessageProducer`
which is only one reactive channel adapter overriding `doStop()`
* Verify in the `ReactiveMessageProducerTests` that subscription is cancelled
for delayed data in the `Publisher`
**Cherry-pick to `5.5.x`**
Fixes https://github.com/spring-projects/spring-integration/issues/3506
Revise the `@Poller` usage in the messaging annotations from an array value
to a single entry with a `ValueConstants.DEFAULT_NONE` for default value
Code review feedback
- Make annotation utils check for NONE more generic
- Move docs to whats-new.adoc
- Polish javadoc
Code review feedback
- simplify docs
- simplify isProvided checks
Fixes https://github.com/spring-projects/spring-integration/issues/3501
* make current with latest changes in 'spring-graphql'
* fix checkstyle issues
* implement reactive endpoint for GraphQL Query
* refactor to handle GraphQL Query and Mutation requests
* refactor to handle GraphQL Subscription requests
* implement expressions to handle for various RequestInput parameters
* convert classes to records in tests, remove unneeded datatype modifiers on channels
* replace executionId with idExpression SpEL evaluator
* adjust name and default expression for executionId
* rename for consistency, remove unneeded null check
* Clean up code style
* Remove redundant variables
* Add `What's New` entry
* Add `package-info.java`
* 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.4.x`**
* Add outbound channel adapter example
* Add an example for the `CustomReactiveMessageHandler` usage
* Emphasize that the examples are for Reactive Streams
* Fix a missing letter that caused the text to get inside the code block
* Emphasize that the first example is an event driven inbound channel adapter
* Fix a redundant question mark from the example code
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`**
