* INT-4480: Use component type for ids in the flow
JIRA: https://jira.spring.io/browse/INT-4480
For better readability of bean names, e.g. from the metrics collectors,
generate them from the component type instead of their fully qualified
class names
* * Fix bean name for injection in the WebFluxDslTests
JIRA: https://jira.spring.io/browse/INT-4457
When an `IntegrationFlow` is reply-based (we expect a reply in the
beginning) and `log()` (or `wireTap()`) is used in the end, we are
forced to add an empty `bridge()` in the end to ensure a `replyChannel`
header routing
* Fix `IntegrationFlowDefinition` to add `enrichHeaders()` in the end
to populate a `nullChannel` as a `replyChannel` header if that is missed
in the request message headers.
This way we cover both use-cases when we expect reply from the flow and
when it is used as a one-way scenario
* Improve a `HeaderEnricher` do not create a new `Message` if there are
no new headers to add/remove
* Remove a note from the `dsl.adoc` about now redundant `bridge()` after
`log()`
* Resolve TODO in the `.handle()` paragraph
* Restore anonymous class in the MessageHistoryIntegrationTests:
Mockito can't mock/spy lambdas because they are `final` classes
* Introduce `IntegrationFlowDefinition.logAndReply()` operator
* Fix logging message
Doc Polishing
Packages with `@Nullable` annotations need to have `@NonNulApi` at the package level.
There may be classes in these packages that have nullable arguments/returns that are
not currently marked as `@Nullable`. These will be fixed over time.
Also suppress JSR305 warnings when compiling tests.
* Polishing - PR Comments
* Fix memory leak in MHistorConfig & MBeanExpHelper
The `MessageHistoryConfigurer` is a `BeanPostProcessor` which keeps a
store of the `TrackableComponent`.
Something similar we have with the `MBeanExporterHelper` and its local
stores populated by the `postProcessBeforeInitialization()`
* Implement `DestructionAwareBeanPostProcessor` in the
`MessageHistoryConfigurer` and `MBeanExporterHelper` to remove destroyed
beans from their caches
**Cherry-pick to 5.0.x**
* * Fix concurrency and checkstyle
* Apply Java 8 style for collections iterations
JIRA: https://jira.spring.io/browse/INT-4513
The `IntegrationManagementConfigurer` keeps metrics beans in its local
stores.
When we add beans at runtime, they are not removed from those caches
after their removal
* Implement `DestructionAwareBeanPostProcessor` in the `IntegrationManagementConfigurer`
and clean up caches according provided bean type and its name
* Improve `ManualFlowTests` and `FtpTests` to be sure that
`IntegrationManagementConfigurer` caches are cleared after destroying
`IntegrationFlowRegistration`
**Cherry-pick to 5.0.x**
JIRA: https://jira.spring.io/browse/INT-4514
`getBeansOfType()` with eager init does not currently return late registered singletons.
We should not be eagerly initializing here anyway.
**cherry-pick to 5.0.x**
JIRA: https://jira.spring.io/browse/INT-4510
Related to https://github.com/reactor/reactor-core/issues/1290
The `Flux.publish()` and subsequent `connect()` doesn't fuse a subscriber
for the hooks flow is interrupted (complete, or error, or disconnect).
In this case the `FluxMessageChannel.publishers` store is not cleared
from the finished publishers
* Add test-case to check the `FluxMessageChannel.publishers` store after
finishing the stream
* Add `hide()` operator with TODO to remove when an appropriate Reactor
version is ready
**Cherry-pick to 5.0.x**
https://build.spring.io/browse/INT-MASTER-1134
According the latest released reactor-core-3.2.0.M2, there is no yet
a `.onErrorContinue()` operator.
We need to stick with the `.errorStrategyContinue()` for time being
This might be a fact that application doesn't use a single
`RedisOperations`.
Also the same JVM may be shared between several applications with
different connections to different Redis servers
* change plain `Boolean unlinkAvailable` property to the
`Map<RedisOperations<?, ?>, Boolean>` and `computeIfAbsent()` per
provided `RedisOperations`
JIRA: https://jira.spring.io/browse/INT-4509
To avoid a re-usage of the `AbstractReplyProducingMessageHandler`,
the `IntegrationFlowDefinition` and `AbstractStandardMessageHandlerFactoryBean`
have a `static Set<>` to store already used producers and check it for
newly provided.
These stores are not cleaned when beans are destroyed leading to memory
leaks
* Implements a `DisposableBean` for the `AbstractStandardMessageHandlerFactoryBean`
to remove its `replyHandler` from the `referencedReplyProducers` on
`destroy()`
* Introduce a `IntegrationFlowDefinition.ReplyProducerCleaner` - an
`DestructionAwareBeanPostProcessor` to clean up removing `MessageProducer`
from the `IntegrationFlowDefinition.REFERENCED_REPLY_PRODUCERS`
**Cherry-pick to 5.0.x**
JIRA: https://jira.spring.io/browse/INT-4507
* Add `RedisUtils` with the `isUnlinkAvailable()` to check the Redis
server version to be sure that `UNLINK` is available or not
* Use `RedisUtils.isUnlinkAvailable()` in the `RedisMessageStore` and
`RedisLockRegistry` when a removal functionality is performed
* Add `AbstractKeyValueMessageStore.doRemoveAll(Collection<Object> ids)`
for optimization
* Implement `doRemoveAll()` in the `RedisMessageStore` and
`GemfireMessageStore`
**Cherry-pick to 5.0.x**
JIRA: https://jira.spring.io/browse/INT-4506
Capture the actual splitter result in the `FunctionIterator and close it if necessary.
**cherry-pick to 5.0.x**
Add Closeable to proxy in test; remove AutoCloseable check.
Closeable extends AutoCloseable.
Fix javadocs; test for AutoCloseable instead of Closeable
Polishing - PR comments; tighten up API.
A `CloseableIterator` is now an `AutoCloseable` with an overridden
`close()`` (no exception) to avoid lint problem.
* Polishing omissions, code style and `@author`
**Cherry-pick to 5.0.x**
* INT-4381: MessageSources refactoring
JIRA: https://jira.spring.io/browse/INT-4381
* Make all the out-of-the-box `MessageSource` implementations based
on the `AbstractMessageSource`
* Fix `JdbcPollingChannelAdapterIntegrationTests` for sporadic failure
because of `fixed-rate` for the poller
* Fix HeaderEnricherTests race condition
The `errorChannel()` expect an error in the `testErrorChannel` after
`1000` ms, but at the same time the `poller` in configured for the
`3000` ms.
* Increase all the timeouts for replies
* Decrease a `fixed-delay` on the `poller`
* Some other code style polishing for the `HeaderEnricherTests`
JIRA: https://jira.spring.io/browse/INT-4503
Custom `ErrorHandler` can't be used if an external `RestTemplate`
is provided
* Replace `isClientSet()`` with ``!isClientSet()`` for `isTrue`
assertion in `errorHandler` method
* Replace assertion of `restTemplate` `isNull` with assertion
`!isClientSet()` `isTrue` in the `requestFactory()` method
* Add test coverage for the `errorHandler` into the `HttpDslTests`
**Cherry-pick to 5.0.x**
JIRA: https://jira.spring.io/browse/INT-4502
Documentation
Using a BiConsumer instead of a custom interface
Doc fixes
Calling callback while locked
More requested fixes
Missing `FileWritingMessageHandler.this` on `fileExistsMode`
* The `SimpleBrokerMessageHandler` has been fixed the way it consults
a `session` store for sending reply.
The session can be added to that store only when we send a `CONNECT`
command.
Fix `WebSocketInboundChannelAdapter` to send additional `CONNECT` message
in the `afterSessionStarted()` and when selected `SubProtocolHandler` is
a `StompSubProtocolHandler`
* Add extract check into the `StompIntegrationTests` for events: now
we also get a `SessionConnectedEvent` as well
* Fix typo in the `index-docinfo.xml`
Removed the backticks that were making links not render. Fixed a few typoes, too.
Integrating feedback from Artem
Artem caught some errors that I had made (and that my editor, Atom, had made - grrr). I fixed them.
Thanks, Artem. :)
Removing duplicate content
I caught that duplicate content somehow got added to preface.adoc. I removed one set of it to make that content not be duplicated.
* Fix `jdbc.adoc` typos
JIRA: https://jira.spring.io/browse/INT-4501
The call to the `IntegrationFlowBeanPostProcessor#setBeanFactory`
happens during BPP creation.
The introduced call to `beanFactory#getBean` triggers a lot of bean
creations.
For those beans not all `BPP`s are applied.
* Obtain a `flowContext` bean in lazy-load manner
**Cherry-pick to 5.0.x**
