JIRA: https://jira.spring.io/browse/INT-4525
Hard-coded 2 second delay is now configurable.
Also fix the logic for creating the SpEL evaluation context.
**cherry-pick to 5.0.x**
* Polishing according PR comments
Creating a EPHEMERAL_SEQUENTIAL node was being used to ensure the
Zookeeper connection had been established. These were never explicitly
removed, which led to tryLock effectively leaking zNodes until the
client was terminated. This in turn lead to an extremely large number of
ephemeral nodes being deleted whenever a long running service
terminated!
This fix replaces the creation of a node with a stat of "/" instead.
This has the desired effect of re-establishing the Zookeeper connection,
but is a read-only operation.
* Remove unused import
* Add Micrometer metrics capture for the
`PollableAmqpChannel` and `PollableJmsChannel`
* Polishing and optimization for the `AbstractPollableChannel.receive()`
**Cherry-pick to 5.0.x**
Make key/trust store types configurable; add a test with host violation.
* Fix some typos and code style in the related classed and docs
* Add asserts for the store type properties
JIRA: https://jira.spring.io/browse/INT-4527
Fixes https://github.com/spring-projects/spring-integration/issues/2543
- Add error handling within the scope of a transaction
- Add `retryDelay` and `maxAttempts`
- Include the delivery attempt header in the `ErrorMessage`
- Add `transactionalRelease()` methods to the DSL
Check context in `ContextRefreshedEvent`.
Complete test case; don't schedule for re-release after a successful send after a failure.
Use `identityHashCode` for deliveries map key - error flow might change the message `hashCode`.
Debug logging
Polishing; remove parameter from the `DelayerEndpointSpec.transactionalRelease()`
* Polishing some code style
- inconsistent use of internal `TimeUnit`
- `setPeriod()` applied the unit, but `getPeriod()` did not
This test failed...
```java
@Test
public void testTriggerConsistency() {
final DynamicPeriodicTrigger trigger = new DynamicPeriodicTrigger(10, TimeUnit.SECONDS);
trigger.setPeriod(trigger.getPeriod());
assertThat(trigger.getPeriod(), equalTo(10_000));
}
```
Change the trigger to use `Duration` and deprecate the other methods.
https://build.spring.io/browse/INT-MASTER-1165/
The test checks how much time have we spent for the process.
It's too hard to be precise in all the environment, especially on slow
CI servers
* Make some code style polishing in the `AggregatorTests`
https://build.spring.io/browse/INT-MASTERSPRING40-441
Even if we `stop()` a `SourcePollingChannelAdapter` that doesn't mean
that task-in-progress can't deliver its result to the source consumer.
* Wrap a list `add()` and iterator operations to avoid a
`ConcurrentModificationException`
* Add `@SuppressWarnings("serial")` for the `RequestMessageHolder`
* Use non-caching JMS CF for the Inbound endpoints in the `JmsTests`
* Make `AsyncGatewayTests extends ActiveMQMultiContextTests` to keep
embedded broker opened in between test methods
* INT-4519: Improve JMS inbound-c-a receiveTimeout
JIRA: https://jira.spring.io/browse/INT-4519
* Modify `DynamicJmsTemplate` to default for `-1` if we get
`CachingConnectionFactory` and it is with `cacheConsumers`, otherwise
1 second
* Polishing for some JMS XML parsers, in particular remove
`receiveTimeout` population
**Cherry-pick to 5.0.x**
* * Polishing according PR comments
* * Properly use a `CachingConnectionFactory` in `JmsTests`
* Add Java DSL `.fluxTransform(Function)` operator
For better interoperability with Reactor `Flux` from the
end-user perspective introduce an operator which could
call a target `Function` with integration data wrapped to the `Flux`
and expect a `Publisher<?>` result to continue the flow.
This way end-user just needs to implement a `Function` (or method)
to accept the `Flux` as an input and return some `Publisher`
after the sequence of reactive operators.
Such a new operator also allows a smooth integration with the
Spring Cloud Function, where it is just enough to lookup the function
in the catalog and inject it into this operator
* * Move `fluxTransform()` body to `Transformers` for cleaner context
distribution
There is a race condition when Zookeeper `LeaderInitiator` may start
earlier than `CuratorFramework` it depends on.
This is because both of them are configured for the same default `phase` (`0`)
* Make `LeaderInitiator` and `LockRegistryLeaderInitiator` to be started
in the `Integer.MAX_VALUE - 1000` phase by default - as late as possible
* Make `CuratorFrameworkFactoryBean` to start in the `Integer.MIN_VALUE + 1000`
phase - as early as possible
* Alight lifecycle properties from the `LeaderInitiatorFactoryBean` with
defaults in the `LeaderInitiator`
* Simplify a `LeaderListenerParser` to rely on the `LeaderInitiatorFactoryBean`
**Cherry-pick to 5.0.x**
* INT-4517: Refactor beans in IntegrationRegistrar
JIRA: https://jira.spring.io/browse/INT-4517
The `IntegrationRegistrar` populates beans into the application context
too early and when the `allowBeanDefinitionsOverride` is disabled we
end up with the `BeanDefinitionOverrideException` just because end-user
beans are applied later.
* Move most of the bean definitions which can be overridden in the target
application from the `IntegrationRegistrar` into the
`DefaultConfiguringBeanFactoryPostProcessor`
* Revise their registration logic to be sure that some of them are
registered only once in the parent context nad others are registered
in the child context as well
* Refactor a `DslIntegrationConfigurationInitializer` do not register
an `IntegrationFlowDefinition.ReplyProducerCleaner` in the child context
one more time: it doesn't bring any local store within the current
child context
* Introduce a `NoBeansOverrideAnnotationConfigContextLoader` in tests
to ensure that in some test-cases we disallow an
`allowBeanDefinitionsOverride` as it is now in Spring Boot since it is
enabled by default in the Spring Framework
* Revernt DslIntegrationConfigurationInitializer changes
Regsiter all the required infrastructure beans in all the application
contexts to avoid class loader issue for `static` store access
JIRA: https://jira.spring.io/browse/INT-4518
* Fix `BridgeFromAnnotationPostProcessor` do not resolve `outputChannel`
for the target `BridgeHandler`
* Rework logic in the `AbstractMethodAnnotationPostProcessor` to do not
resolve a `MessageHandler` bean from the `@Bean` method when we can
just check a method return type.
* Check `BeanDefinition` instead of real bean when we consult for
conditions
**Cherry-pick to 5.0.x**
* 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**
