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
Related to: #8856
Many tests create their own `ThreadPoolTaskScheduler` beans.
Therefore, its default phase might affect the memory and performance.
* Use `phase = SmartLifecycle.DEFAULT_PHASE / 2` for manual
`ThreadPoolTaskScheduler` beans
* Migrate affected tests classes to JUnit 5
* Make some other configuration adjustments for better performance
**Cherry-pick to `6.2.x`**
* GH-3946: Revise Router channelKeyFallback option
Fixes https://github.com/spring-projects/spring-integration/issues/3946
The `AbstractMappingMessageRouter` has both `resolutionRequired` and `channelKeyFallback`
as `true` by default.
End-users expects them to back off when they set a `defaultOutputChannel`.
They really want something similar to Java `switch` statement
* Change the logic in the `AbstractMappingMessageRouter` to reset `channelKeyFallback`
to `false` when `defaultOutputChannel` to avoid attempts to resolve channel from name,
but rather fallback to `defaultOutputChannel` as it states from th mentioned
Java `switch` statement experience
* Deprecate `RouterSpec.noChannelKeyFallback()` in favor of newly introduced `channelKeyFallback(boolean)`
* Call `channelKeyFallback(false)` from an overloaded `defaultOutputToParentFlow()`
to reflect the mentioned expected behavior in Java DSL as well.
* Respectively, deprecate `KotlinRouterSpec.noChannelKeyFallback()` wrapper
in favor of newly introduced `channelKeyFallback(channelKeyFallback: Boolean)`
* Remove redundant already `noChannelKeyFallback()` option in the `NoFallbackAllowedTests`
* Document the change and new behavior
* Fix `IntegrationGraphServerTests` to `setChannelKeyFallback(true)` explicitly
* Remove not relevant `default-output-channel` from the `DynamicRouterTests-context.xml`
* Reject an `AbstractMappingMessageRouter` configuration where `defaultOutputChannel` is provided
and both `channelKeyFallback` & `resolutionRequired` are set to `true`.
Such a state makes `defaultOutputChannel` as not reachable and may cause some confusions in target
applications.
* Remove `&` symbol from JavaDocs
* Fix `boolean` expression for `AbstractMappingMessageRouter` configuration check
* Fix `IntegrationGraphServerTests` for new router behavior
* Improve language in docs
Fixes https://github.com/spring-projects/spring-integration/issues/3686
* Add `src/idea` with respective editor config for IntelliJ IDEA.
Must be imported into an IDE
* Add `src/eclipse` with respective editor config for Eclipse/STS
* Reformat imports in source code according a new editor config
* GH-3844: Rework messaging annotation with @Bean
Fixes https://github.com/spring-projects/spring-integration/issues/3844
* Make `MessagingAnnotationPostProcessor` as a `BeanDefinitionRegistryPostProcessor`
to process bean definitions as early as possible and register respective messaging
components at that early phase
* Make bean definitions parsing logic optional for AOT and native mode since beans
have bean parsed during AOT building phase
* Introduce a `BeanDefinitionPropertiesMapper` for easier mapping
of the annotation attributes to the target `BeanDefinition`
* Remove `@Bean`-related logic from method parsing process
* Change the logic for `@Bean`-based endpoint bean names:
since we don't deal with methods on the bean definition phase, then method name
does not make sense.
It even may mislead if we `@Bean` name is based on a method by default, so we end up
with duplicated word in the target endpoint bean name.
Now we don't
* Fix `configuration.adoc` respectively for a new endpoint bean name logic
* In the end the new logic in the `AbstractMethodAnnotationPostProcessor`
is similar to XML parsers: we feed annotation attributes to the
`AbstractStandardMessageHandlerFactoryBean` impls
* * Fix language in docs and exception message
Related to https://stackoverflow.com/questions/72851234/error-in-startup-application-when-using-serviceactivator-in-spring-cloud-stream
The `MessagingAnnotationPostProcessor` register an `endpoint` bean for Messaging Annotation on POJO methods.
The `IntegrationMBeanExporter` post-process such a bean and registers respective MBean.
It does this not in optimal way scanning all the `IntegrationConsumer` beans for requested `MessageHandler`
which may cause a `BeanCurrentlyInCreationException`.
* Rework the logic of the `IntegrationMBeanExporter.postProcessAbstractEndpoint()` to propagate provided endpoint
for the monitor registration to bypass application context scanning for matched name.
* Swap `equals()` for `monitor` since an `extractTarget()` may return `null`
* Some other code clean in the `IntegrationMBeanExporter`
* Change one of the `@ServiceActivator` in the configuration for the `ScatterGatherHandlerIntegrationTests`
to POJO method.
However, this didn't fail for me with original code unlike in the sample application provided in the mentioned SO thread.
**Cherry-pick to `main`**
Fixes https://github.com/spring-projects/spring-integration/issues/3623
* `IntegrationFlow` refactoring
* Apply several code style improvements and good practices
* Code style: no empty lines for methods javadocs
* make deprecated implementation reuse actual one instead of the copy-paste approach
* add whats-new comments
* Fix whats-new page according to standards
* Upgrade Spring dependencies to the latest SNAPSHOTs
* Fix tests to verify against stack traces: the message
of the `NestedRuntimeException` does not include the nested exception information.
Related to https://github.com/spring-projects/spring-framework/issues/25162
* Fix `JdbcMessageStore` and `DefaultLockRepository` to rely on the `DataIntegrityViolationException`
instead of only its `DuplicateKeyException` extension.
This is the current behavior of the SQL errors translation
* Disable `WebFluxDslTests.testValidation()` - doesn't subscribe to the reply somehow...
* Refine `SimplePool.PoolSemaphore.reducePermits()`
* Add recommended JVM args to the Gradle module for HZ performance
* Move `IdempotentReceiverIntegrationTests` from JMX module to HZ for consistency
* Remove component scan from the `HazelcastIntegrationOutboundTestConfiguration` - redundant
* Use `HazelcastInstance.shutdown()` during normal context lifecycle.
The `@AfterClass` may happen early, so the `stop()` of the channel adapters may fail with
an exception that HZ is not available causing the `LifecycleProcessor` to wait for 30 seconds
on the lifecycle barrier
* Wrap `AbstractEndpoint.doStop()` call into `try..catch` to log error instead of re-throwing
to avoid the mentioned above 30 secs delay of the application context stop
Fixes https://github.com/spring-projects/spring-integration/issues/3592
* Configure XML parser & Java DSL for Scatter-Gather, based on the
`RecipientListRouter` to set an `applySequence` to `true` by default.
This will make a `gatherer` part to fully rely on the default correlation
strategies
Fixes https://github.com/spring-projects/spring-integration/issues/3541
* Fix `DefaultConfiguringBeanFactoryPostProcessor` to check for `jsonPath` bean
a `com.jayway.jsonpath.JsonPath` on CP instead of `JsonPathUtils`
which is always there since it is a part of `spring-integration-core`
* Remove `json-path` and `jackson-databind` from tests classpath
to be sure that we have coverage for the mentioned above option classpath entries
* Add `json-path` and `jackson-databind` into test classpath whenever it is necessary
* GH-3386: Add method signature for gateway proxy
Fixes https://github.com/spring-projects/spring-integration/issues/3386
All the gateway proxy method invokers are supplied with the same
bean name inherited from the proxy.
* Add method signature for proxy method bean to fine-grain the
management for those bean in the logs, message history and metrics
* * Use `Class.getSimpleName()` instead to make gateway names less verbose
- Simplify MBeans - instead of wrapping to expose lifecycle methods,
implement `ManageableLifecycle`. Register an additional MBean for
polled endpoints to control the lifecycle.
* Polishing
- Move `QueueChannel` `@ManagedAttribute`s to `QueueChannelOperations`
- Make all `AbstractEndpoints` `IntegrationManagedResource`s and remove `ManagedEndpoint`
to allow exposure of any `@Managed*` methods (including those on `Pausable`)
- Revert to `Lifecycle` for classes that are not related to endpoints
- Remove legacy metrics from docs
* Support Java 14
* Provide changes to avoid deprecated Java API
and have a compatibility back to Java 8
* Change affected test classes to JUnit 5 whenever it is possible
* Ignore/Disable some TCP/IP tests which don't pass on Java 14
* Fix (some) TCP tests on JRE 14
* Fix SSL Handshake test - client side handshake is successful with java 14
- change the badClient cert to a badServer cert to force an error on the client side
Co-authored-by: artembilan <raven666>
Co-authored-by: Gary Russell <grussell@pivotal.io>
- add a module to suppress legacy metrics from the Integration Graph
- move graph tests package to match src/main
Fix missed deprecation and checkstyle.
More deprecations and remove GraphLegacyStatsNullModule.
* Revert GRAPH_VERSION.
* Fix JavaDocs warnings
* Fix `MBeanExporterParserTests`
* GH-2748: Add bean definition info into exceptions
Fixes https://github.com/spring-projects/spring-integration/issues/2748
In many cases Spring Integration stack traces doesn't contain any
relations to end-user code.
Just because a target project code mostly contains only a configuration
for out-of-the-box components without any custom code.
When exception is thrown from such an out-of-the-box component, it is
hard from the stack trace to determine a configuration source for those
components.
* Add a logic into the `IntegrationObjectSupport` to obtain a its own
`BeanDefinition` from the `BeanFactory` to include a `resource` and
`source` (if any) into the `toString()` representation, as well as add
a new `getBeanDescription()` to get such an info at runtime
* The `toString()` is simply used by `this` reference in the message
for `MessagingException` thrown from the `IntegrationObjectSupport`
implementations
* Modify an exception message for the `MessageTransformingHandler` and
`MessageFilter` to make it based on `this`.
The `AbstractMessageHandler` already includes `this` into its exception
message
* Modify a `AbstractConsumerEndpointParser` and
`AbstractAmqpInboundAdapterParser` (as a sample) to include a `resource`
and `source` into a `MessageHandler` `BeanDefinition`.
* Include an `IntegrationFlow` `BeanDefinition` `resource`
(`@Configuration` class) and its bean method as a `source` into all
child beans declared during flow parsing in the `IntegrationFlowBeanPostProcessor`
* Add `IntegrationFlowRegistrationBuilder.setSource()` for manually
registered flows: there is no configuration parsing phase to extract
such an info from `BeanFactory`
* Propagate that `source` into all the child beans provided by the
`IntegrationFlow`
* Modify a `LambdaMessageProcessor` exception message to include a
method info in case of `InvocationTargetException`
* Do not cast explicitly for `ConfigurableListableBeanFactory` in the
`IntegrationObjectSupport` to avoid tests modifications for mocking
directly into `ConfigurableListableBeanFactory`.
Use `instanceof` instead in the `getBeanDescription()`
* * Fix Checkstyle issues
* * Fix `IntegrationGraphServer` and `IntegrationMBeanExporter`
to rely on the `NamedComponent` for channel names instead of
always call `toString()` which is now much more than just a bean name
* Don't describe a `componentName` if it is the same as a `beanName`
* Check for parent `BeanDefinition` in the `IntegrationFlowBeanPostProcessor`
before calling its meta-info
* Fix tests according new `IntegrationObjectSupport.toString()` behavior
JIRA: https://jira.spring.io/browse/INT-4573
* Fix check order for headers first in the `resolveObjectName()` and
`resolveOperationName()`.
Then fallback to defaults configured on the `OperationInvokingMessageHandler`
* Remove also a deprecated API in the `OperationInvokingMessageHandler`
* Remove requirements for `object-name` and `operation-name` XML
attributes since those options can be provided in the request message
headers
* Fix `OperationInvokingChannelAdapterParserTests` for proper headers
resolution
* Mention `JmxHeaders.OBJECT_NAME` and `JmxHeaders.OPERATION_NAME`
headers in the `jmx.adoc`
* GH-2749: Deprecate ChannelInterceptorAware
Fixes https://github.com/spring-projects/spring-integration/issues/2749
The `org.springframework.messaging.support.InterceptableChannel` provides
exact functionality as `ChannelInterceptorAware`
* Make `ChannelInterceptorAware extends InterceptableChannel`
* Suppress deprecation warning whenever we need to keep backward
compatibility
* Fix all other places to deal with `InterceptableChannel` already
* GH-2749: Deprecate ChannelInterceptorAware
Fixes https://github.com/spring-projects/spring-integration/issues/2749
The `org.springframework.messaging.support.InterceptableChannel` provides
exact functionality as `ChannelInterceptorAware`
* Make `ChannelInterceptorAware extends InterceptableChannel`
* Suppress deprecation warning whenever we need to keep backward
compatibility
* Fix all other places to deal with `InterceptableChannel` already
* * Fix `channel.adoc` for the current version
Mostly thanks to IDEA's plugin: https://plugins.jetbrains.com/plugin/10345-assertions2assertj
There is still a lot of work to do when complex and composite matchers are used.
* Add `awaitility` dependency and deprecate `EventuallyMatcher` in favor
of `awaitility`
* Remove Hamcrest from dependencies and disable JUnit & Hamcrest
static imports to encourage to use only AssertJ
* Migrate JUnit assumptions in rules to AssertJ's assumptions
* Deprecate some custom matchers in favor of existing in Hamcrest
after upgrading the last to version `2.1`
* Replace `ExpectedException` rules with `assertThatThrownBy()`
* Mention `MessagePredicate` in the `testing.adoc`
Fixes https://github.com/spring-projects/spring-integration/issues/2744
When we get scattering results, there is no reason to keep internal
headers any more.
* Fix `ScatterGatherHandler` to modify scattering result messages to
reinstate headers from original request message.
This way we are able to re-throw an exception from the gatherer to
the caller.
* Fix typos and language in Docs
JIRA: https://jira.spring.io/browse/INT-2549
* Add `expectReply` property into the `OperationInvokingMessageHandler`
to align the one-way and request-reply behavior with all other similar
components in Spring Integration
* Ignore an operation invocation result in case of `expectReply == false`
and log warning
* Provide some refactoring into the `OperationInvokingMessageHandler`
to fix Sonar complains about complexity
**Cherry-pick to 5.0.x, 4.3.x**
* Fix wrong import order in tests
* Polishing for not closed application contexts
* Use diamonds
* Use proper assertion operators
* Remove redundant classes
* Improve performance in JPA tests
* Fix typos
* INT-4544: Allow runtime MBeans (un)registered
JIRA: https://jira.spring.io/browse/INT-4544
* Fix `SourcePollingChannelAdapterFactoryBean` to register an
`outputChannelName` into the `SourcePollingChannelAdapter` for late
binding, especially in case of dynamic `IntegrationFlow` registrations.
This must be back-ported to `5.0.x`
* Implement `DestructionAwareBeanPostProcessor` in the
`IntegrationMBeanExporter` for the runtime beans tracking, e.g. via
dynamic `IntegrationFlow` registrations
* Refactor `IntegrationMBeanExporter` for static and dynamic beans
registration and destruction
* Remove unused properties; introduce some new for tracking beans and
their relationship
* * Move `IntegrationMBeanExporter.registerProducer()` after
`postProcessAfterInitialization()`
* Refactor JMX test configurations to reuse MBeanServer as much as
possible and destroy the server whenever it is necessary
* * More JMX tests polishing
* * And more JMX tests polishing
* * `try...catch` in the `IntegrationMBeanExporter.postProcessAfterInitialization()`
to avoid breaking changes for the current GA phase
* Do not unregister those MBeans explicitly which weren't created at
runtime
* * Log ObjectNames in the `MBeanExporterIntegrationTests`
* * Fix `MessageMetricsAdviceTests` to rely on the application context
* Do not use a cst in the `StandardIntegrationFlowContext` for
`BeanFactory`, but an explicit `BeanDefinitionRegistry`
* Extract targets from proxies in the
`IntegrationMBeanExporter.postProcessAfterInitialization()`
* Remove logging in the `MBeanExporterIntegrationTests`
* * Fix `NotificationListeningMessageProducerTests` to reuse existing `MBeanServer`
* * Change JMX `domain` in the `DslMBeanTests` to `dsl` do not clash with
similar in the `foo` in the `MessageSourceTests`
* Use `MBeanServer` bean in the `Int2307Tests`
* Use JUnit 5ctor injection injection in the `MessageMetricsAdviceTests`
* * Fix JMX tests do not reuse existing `MBeanServer` and make them rely
on the server provided by the managed `MBeanServerFactoryBean` which
destroys a server on application context close
* Fix `StoredProcJmxManagedBeanTests-context.xml` to use `MBeanServer`
from the `<context:mbean-server>`
https://www.oracle.com/technetwork/java/javase/tech/best-practices-jsp-136021.html
The set of characters in a value is also limited. If special characters may
occur, it is recommended that the value be quoted, using ObjectName.quote. If
the value for a given key is sometimes quoted, then it should always be quoted.
By default, if a value is a string (rather than a number, say), then it should
be quoted unless you are sure that it will never contain special characters.
Practically, some special characters are allowed, but we will standardize on
allowed characters in java identifiers.
JIRA: https://jira.spring.io/browse/INT-4390
Phase I: flow context/registration cycle
- extract interfaces
- rename implementations to `Standard...`
Phase II - dsl<->dsl.channel tangles
Move the channel specs to dsl.
Fix missing refactorings
(Not related to DSL) - rename core `event` package to `events`
- avoid collision with event module package
- fix tangle caused by `MessageGroupExpiredEvent`.
Phase III - dsl<->config.dsl
- move classes from config.dsl to dsl
(Not related to DSL) - fix many tangles caused by graph being a sub-package of support.management
- make `graph` a top-level package
(Not related to DSL) - move `IntegrationManagementConfigurer` from
`management` to `config` - tangle between core and management
* Polishing Copyrights, diamonds, some JavaDocs and What's New
According Reactor recommendation it would be better to `CoreSubscriber`
from Reactor instead of Reactive Streams `Subscriber` for chasing
some optimisation in case of Reactor flows
Increase `receive()` timeout in the `AttributePollingChannelAdapterParserTests`
* Fix `ControlBusParserTests` test to pass `Object.class` to the
`MessageConverter` since we can't use `null` there any more
* Fix `JmsOutboundGateway` for empty string for the
`replyDestinationName` since we can't pass `null` there any more
* Upgrade to Gradle 3.5, SS-5.0, Hibernate-5.2.10, Mockito-2.7.22, Pah-1.1.1
And some other minor upgrades
* Fix deprecations for Mockito compatibility
* Fix `ServletWebSocketHandlerRegistry` deprecations
* Fix SD-Mongo deprecations
* Tweak JMX tests to avoid dangling threads after tests exist
* Increase timeouts in some polling tests
JIRA: https://jira.spring.io/browse/INT-4174
I considered just using the channel counter but I suppose there is a (small) possibility
that someone might possibly use a custom dispatcher and subscribe to it directly.
Polishing -- ** master only **
Eliminate conditional logic in AbstractMessageChannel by adding getHandlerCount() to
MessageDispatcher.
Do not cherry pick.
* Also fix JPA tests model for proper database `sequence` to avoid race condition when the test data is inserted with lower `id` than expected predefined data has
JIRA: https://jira.spring.io/browse/INT-3770,
https://jira.spring.io/browse/INT-4107
Having `TransactionHandleMessageAdvice` we can start TX from any `MessageHandler.handleMessage()`
* Add `<transactional>` alongside with the `<request-handler-advice-chain>` for those components which produce reply
* Merge `<transactional>` and `<request-handler-advice-chain>` configuration to a single `ManagedList`
* Rework JPA `<transactional>` in favor of common solution
* Some polishing and refactoring
AbstractPollingEndpoint: avoid `new ArrayList` if we don't have `receiveOnlyAdvice`s
JIRA: https://jira.spring.io/browse/INT-4095
Limit the number of remote files fetched on each poll (when it is necessary to fetch files).
Polishing - PR Comments
Polishing - Decouple MaxFetchSize from Poller
Polishing - PR Comments
Schemas and Docs
More Polishing
* Polishing according PR comments
JIRA: https://jira.spring.io/browse/INT-4064
We configure `IdempotentReceiver` via `<int:idempotent-receiver>` component or `@IdempotentReceiver` annotation.
In case of regular Java config, e.g. direct `ConsumerEndpointFactoryBean` usage or Java DSL,
it isn't possible to configure `idempotentReceiverInterceptor` enough easy
* Introduce `if...else` logic into `ConsumerEndpointFactoryBean` to proxy `MessageHandler`,
if `adviceChain` contains an newly-introduced `HandleMessageAdvice`.
And do that independently if `MessageHandler` is `AbstractReplyProducingMessageHandler`
* Make `idempotentReceiverInterceptor extends HandleMessageAdvice`
* Skip `HandleMessageAdvice` in the `AbstractReplyProducingMessageHandler`
* Add advice applying logic into the `AbstractMethodAnnotationPostProcessor` as well
Introduce `HandleMessageAdvice` marker interceptor to cover the case when an `Advice` can be advices as well.
Remove unused `setAdviceChainIfPresent()` method in the `AbstractMethodAnnotationPostProcessor`
Document `HandleMessageAdvice`
Increase wait latch timeouts in the `LockRegistryLeaderInitiatorTests`
Doc Polishing
* Upgrade to SA and SF snapshots
* Address TODOs regarding those upgrades
* Resolve some other TODOs
* Replace `PropertyPlaceholderConfigurer` beans with the `<context:property-placeholder>`
* Upgrade to Spring Social Twitter 1.1.2 and resolve deprecations via mocks (https://github.com/spring-projects/spring-social-twitter/issues/91)
* Upgrade to Curator `3.1.0` and resolve deprecation in the `ZookeeperMetadataStore`
