The time-based tests are very sensitive to an activity on the target machine.
So, strict test sometimes fail.
* Fix `DelayerUsageTests` to deal with approximate values to compare by some percentage
Fixes https://github.com/spring-projects/spring-integration/issues/3953
The replying `MessageHandler` can resolve the target output channel in on-demand manner.
A new messaging annotations on `@Bean` parsing algorithm is missing the lazy-load
opportunity and uses a `RuntimeBeanReference` for output channel options
loading its bean eagerly.
* Fix `AbstractMethodAnnotationPostProcessor` to use a `outputChannelName` and
`defaultOutputChannelName` target properties for channel names to set.
* Expose more reflection hints
* Bring back `@Reflective` on `Pausable` - for possible end-user usage
* Add `ReactiveMessageHandler` hint since its method is used reflectively
in the `IntegrationRSocketMessageHandler`
* Add `@Reflective` on the `ServerRSocketMessageHandler.handleConnectionSetup()`
since it is used reflectively for a `registerHandlerMethod()`
* Add `KafkaRuntimeHints` to expose `Pausable` contract on Kafka inbound endpoints
for SpEL invocation via Control Bus
* Document native images support
* Fix language in docs
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
* Also register `Pausable` explicitly and remove its `@Reflective`.
This type is needed for Control Bus SpEL execution, but it might not
be available at runtime because not all endpoints implement it
The `Pausable` & `ManageableSmartLifecycle` types are eligible to be used
from Control Bus.
This one is based on SpEL and therefore requires a reflection for those
types to be available in native image
* GH-3555: Change logger order for errorChannel
Fixes https://github.com/spring-projects/spring-integration/issues/3555
The default global `errorChannel` has a `LoggingHandler` as a subscriber.
It is subscribed without any `order` which may lose logging messages,
when another subscriber with re-throw is present.
* Set default `LoggingHandler` on the default `errorChannel` to `Ordered.LOWEST_PRECEDENCE - 100`
to give a room for custom subscribers without an `order` and still get error logged
* Add extra note in docs about an order for custom subcribers
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
* 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
The `GatewayProxyInitializationAotProcessor` uses mistakenly a `ProxyFactoryBean` type
instead of an expected `GatewayProxyFactoryBean`.
Looks like we don't need to scan for interfaces since they are properly transformed
to the `AnnotationGatewayProxyFactoryBean` bean definition during AOT phase
* GH-3945: Fix `not eligible for getting processed`
Fixes https://github.com/spring-projects/spring-integration/issues/3945
The `IntegrationManagementConfiguration` produces an `IntegrationManagementConfigurer` which is a `BeanPostProcessor`.
According to Spring recommendation this kind of infrastructure beans must be declared as `static`.
Due to an `implements ImportAware, EnvironmentAware` nature of the `IntegrationManagementConfiguration`,
we cannot use `static @Bean` method.
But since the `IntegrationManagementConfiguration` is not involved in any bean post-processing,
it is safe to follow recommendation and mark it as a `@Role(BeanDefinition.ROLE_INFRASTRUCTURE)`.
* Fix `MessagePublishingInterceptor` to initialize `MessagingTemplate` and `DestinationResolver` lazily
* Fix `AbstractMethodAnnotationPostProcessor` to initialize `DestinationResolver` lazily
**Cherry-pick to `5.5.x`**
* * Use `getChannelResolver()` internally in the `AbstractMethodAnnotationPostProcessor`
instead of direct property access which might not be initialized yet
* Use a plain `boolean` for `templateInitialized` in the `MessagePublishingInterceptor`
to avoid skips in other thread where and move on with still not initialized properties
* * Remove unused import
* * Fix `this.` prefix for `beanFactory` property reference
* Add observation for message channels
* Add observation for message channels
The `MessageChannel.send()` is, essentially, only the point in Spring Integration where we produce a message
and can emit a `PRODUCER` kind span.
* Implement `IntegrationObservation.PRODUCER` infrastructure based on the `MessageSenderContext`
* Implement an observation emission in the `AbstractMessageChannel` based on the mentioned `IntegrationObservation.PRODUCER`
* Build a `MutableMessage.of(message)` to be able to modify message header in the `MessageSenderContext` via tracer `Propagator`
or other tracing injection instrument
* Document which components are instrumented with an `ObservationRegistry`
* Fix language in docs
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
Turns out the AOT engine deals only with indexed constructor arguments for bean definition
* Rework `GatewayProxyInstantiationPostProcessor.processAheadOfTime()`
to populate a service interface type as an indexed ctor argument instead of generic one
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
The `GatewayProxyInstantiationPostProcessor` does nothing on the AOT phase.
Therefore, scanned and imported beans for `@MessagingGateway` are not decorated
after AOT
* Implement a `BeanRegistrationAotProcessor` in the `GatewayProxyInstantiationPostProcessor`
to `RegisteredBean.getMergedBeanDefinition()` withe respective `AnnotationGatewayProxyFactoryBean`
and its requirements for ctor arg and `targetType`
* Scan for the `@MessagingGateway` bean in the `GatewayProxyInitializationAotProcessor`
to register respective proxy hints
The SF now understands `targetType` on a `BeanDefinition` for `FactoryBean`
* Remove `FactoryBean.OBJECT_TYPE_ATTRIBUTE` from the `GatewayParser`
* Expose `targetType` on a bean definition for an `AnnotationGatewayProxyFactoryBean`
in the `IntegrationFlowBeanPostProcessor` for DSL definitions
* GH-3903: Improve AOT for gateway proxy beans
Fixes https://github.com/spring-projects/spring-integration/issues/3903
* Fix `MessagingGatewayRegistrar` to set a `targetType` on the bean definition
instead of `FactoryBean.OBJECT_TYPE_ATTRIBUTE`
* Rework `GatewayProxyBeanRegistrationAotProcessor` to the
`GatewayProxyInitializationAotProcessor implements BeanFactoryInitializationAotProcessor`
to avoid custom code generation
* Remove tests which rely on the `FactoryBean.OBJECT_TYPE_ATTRIBUTE`
* * Add `setBeanClass(GatewayProxyFactoryBean.class)` to satisfy Spring container expectations
* * Rework `GatewayProxyInitializationAotProcessor` to deal with generics
we are exposing now on the `ProxyFactoryBean`
To avoid duplication for scanning register a `IntegrationComponentScanRegistrar`
as a bean by itself and check for its presence before scanning
* Exclude this bean definition from the AOT since its logic has already passed on AOT generation
and we don't need this bean at runtime any more
* Some code style improvement for SMB classes
* Make an `SmbSessionTests` based on the `SmbTestSupport` for faster execution, but not blocking on fake URL connection attempt
* Remove `AbstractMqttMessageDrivenChannelAdapter.Topic` model in favor of `LinkedHashMap` handling
* Fix gateway proxy for generic interface in XML
Without a `FactoryBean.OBJECT_TYPE_ATTRIBUTE` the application context cannot determine a qualified
with generic an interface injection
* Set back `FactoryBean.OBJECT_TYPE_ATTRIBUTE` in the `GatewayParser`
when not in AOT mode.
Set a `targetType` when used in AOT
* * Remove unused import
* * Fix `GatewayParserTests` for new code base
* Add observation to inbound endpoints
* * Improve `Observation` logic in the `MessageProducerSupport` and `MessagingGatewaySupport`
* Clean up Javadocs in observation support classes
* Add test for `MessagingGatewaySupport` instrumentation into `IntegrationObservabilityZipkinTests`
* Add docs for `@EnableIntegrationManagement.observationPatterns()`
* The generated docs for metrics and spans looks OK: have both `Gateway` and `Handler` section now
* * Fix Checkstyle violations
* * Fix `IntegrationMBeanExporter` to filter out a `MessageProducer` from sources.
Marking a `MessageProducerSupport` with an `IntegrationInboundManagement`
causes it to be considered as a source for JMX.
Technically it might have a reason since it is indeed a source, but that's fully different story
* * No observation instrumentation by default
* * Fix "no observation by default" configuration logic
* GH-3926: BeanNameGenerator for @MessagingGateway
Fixes https://github.com/spring-projects/spring-integration/issues/3926
Current approach for generated bean name in the `MessagingGatewayRegistrar`
is to decapitalize simple class name, which is similar to standard `AnnotationBeanNameGenerator`
* Make logic in the `MessagingGatewayRegistrar` based on the provided `BeanNameGenerator`
* Expose an `@IntegrationComponentScan.nameGenerator()` attribute to allow to customize
default bean name generation strategy
* Introduce `IntegrationConfigUtils.annotationBeanNameGenerator()` to
take a provided `AnnotationConfigUtils.CONFIGURATION_BEAN_NAME_GENERATOR` singleton
or fallback to the `AnnotationBeanNameGenerator.INSTANCE`
* Use this utility in the `IntegrationComponentScanRegistrar` if no custom strategy is provided
in the `@IntegrationComponentScan`
* Use same util from the `GatewayParser` since there is no custom naming strategy configuration
* Some other current Java level refactoring in the `IntegrationComponentScanRegistrar`
and `MessagingGatewayRegistrar`
* * Meta-annotate `@MessagingGateway` with a `@MessageEndpoint`
* Alias `@MessageEndpoint.value()` with a `@Component.value()`
* Alias `@MessagingGateway.name()` with a `@MessageEndpoint.value()`
* * Remove unused imports
* * Replace `MessagingGatewayRegistrar` parsing logic for annotation configuration
directly by the `GatewayProxyInstantiationPostProcessor` and `AnnotationGatewayProxyFactoryBean`.
* The `MessagingGatewayRegistrar` logic has been migrated back to the `GatewayParser`,
but only with an XML-relevant parts
* Change the logic of the `IntegrationComponentScanRegistrar` to rely on a `ClassPathBeanDefinitionScanner`
and its `scan()` functionality since this is all what we need to trigger a `GatewayProxyInstantiationPostProcessor`
for scanned components
* Fix `GatewayProxyInstantiationPostProcessor` to call an `afterPropertiesSet()` as well
* Add a `value()` alias attribute for the `@MessagingGateway` to satisfy a name resolution from a `@Component`
* Replace annotation chain resolution logic by new `MessagingAnnotationUtils.resolveMergedAttribute()` API
* Use `MergedAnnotations` API in the `AnnotationGatewayProxyFactoryBean` to preserve a logic for attribute
resolution from the annotation hierarchy
* Add expression resolution for attribute values in the `AnnotationGatewayProxyFactoryBean`
* Make a `GatewayInterfaceTests.CustomBeanNameGenerator` as an `AnnotationBeanNameGenerator`
extension to satisfy the test logic expectations: no custom name if explicit is present
* Clean up some doc typos after merge conflict
The fix in this commit essentially resolves some old JIRA ticket: https://jira.spring.io/browse/INT-4558
* * Remove redundant `MessagingAnnotationUtils.resolveMergedAttribute()`
* Optimize the logic in the `AnnotationGatewayProxyFactoryBean` around
annotation attributes to plain annotation - no adaptation to maps
* GH-3923: Add @MessagingGateway @Import support
Fixes https://github.com/spring-projects/spring-integration/issues/3923
Currently, the `@MessagingGateway` interfaces can be scanned or created
explicitly as `@Bean` definition for `AnnotationGatewayProxyFactoryBean`
* Implement a `GatewayProxyBeanDefinitionPostProcessor` which is invoked
before instantiation attempt on the `BeanDefinition`
* Verify `@Import` for `@MessagingGateway` interface in the `GatewayInterfaceTests`
* Remove supplier for `GatewayProxyInstantiationPostProcessor` bean definition
Co-authored-by: Gary Russell <grussell@vmware.com>
* * Fix bean definition signature
Co-authored-by: Gary Russell <grussell@vmware.com>
* Fix double start for `AbstractEndpoint`
When we use POJO methods in the `IntegrationFlowAdapter`,
the `IntegrationFlowAdapter` is set as a `target` for the `MessagingMethodInvokerHelper`.
When endpoint is started by the application context, such a `start()` is propagated
down to the `MessagingMethodInvokerHelper`.
And in our case back into an `IntegrationFlowAdapter` instance.
This one, in turn, starts its `IntegrationFlow` internally which leads to the
start of the mentioned endpoint in the beginning.
Therefore, we cause a recursive `start()` call on this endpoint from itself.
The `running` flag is set when we are already done with the `doStart()` logic.
Therefore a recursive `start()` call leads to two concurrent polling tasks
in the `AbstractPollingEndpoint`.
* Check also for the `active` flag in the `AbstractEndpoint.start()`
and reset it in case of exception in the `doStart()`
**Cherry-pick to `5.5.x`**
* * Change assert for message timestamps to `isCloseTo()` with percentage
* * Change `catch` in the `AbstractEndpoint.start()` to `RuntimeException`:
the `doStart()` cannot throw unchecked exceptions by definition
* * Fix imports in `AbstractEndpoint`
* Add generic arg to the `GatewayProxyFactoryBean`
Related to https://github.com/spring-projects/spring-integration/issues/3923
When gateway proxy is declared manually, a `GatewayProxyFactoryBean` is used as a `@Bean`.
In this case the info about target interface is not available on a `BeanDefinition`,
unlike with a programmatic registration via `MessagingGatewayRegistrar`.
* Expose `<T>` on a `GatewayProxyFactoryBean` to make end-user to specify the type
this gateway is going to be based on.
This allows Spring container to determine the type of the `FactoryBean` bean definition
properly
* Migrate a programmatic bean definition registration from the
`FactoryBean.OBJECT_TYPE_ATTRIBUTE` to the `targetType` property
of the `BeanDefinition` based on a `ResolvableType.forClassWithGenerics()`
to simulate generic arg for the application context
* Remove `ComponentsRegistration` from the `GatewayProxySpec` since it us out of use
* Fix affected tests for newly added generic arg on the `GatewayProxyFactoryBean`
* Fix another typo in gateway.adoc
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
* GH-3920: Support @Primary on @MessagingGateway
Fixes https://github.com/spring-projects/spring-integration/issues/3920
Any Spring `@Component` can also be marked with a `@Primary`.
The `@MessagingGateway` for proxying interfaces has no difference with
a standard `@Component` definition
* Modify `MessagingGatewayRegistrar` to obtain a `@Primary` marked
from the `importingClassMetadata` and pass it to the target `BeanDefinition`
* Verify the `@Primary` effect in the `GatewayInterfaceTests`
* Document this improvement
* * Fix Checkstyle violations
The `AbstractMethodAnnotationPostProcessor` makes a decision to use a `MessageHandler`
bean definition as is without wrapping by the type of `MessageHandler`.
There are some of them can be configured via `AbstractSimpleMessageHandlerFactoryBean`,
e.g. an `AggregatorFactoryBean`
* Check for the `AbstractSimpleMessageHandlerFactoryBean` to return as is
* Widen the replying producer by the `AbstractMessageProducingHandler` type
* Add an `AggregatorFactoryBean` with a `@ServiceActivator` configuration to test coverage
* Revert `getMethodValue()` for `CookieTests` since it is removed in the SF SNAPSHOT
* Add `@Suppress("UNCHECKED_CAST")` to `FunctionsTests.kt` to suppress compilation warning
* GH-3902: Add Kotlin Coroutines Support
Fixes https://github.com/spring-projects/spring-integration/issues/3902
* Add `isAsync()` propagation from the `MessagingMethodInvokerHelper`
to the `AbstractMessageProducingHandler` to set into its `async` property.
The logic is based on a `CompletableFuture`, `Publisher` or Kotlin `suspend`
return types of the POJO method
* Introduce `IntegrationMessageHandlerMethodFactory` and `IntegrationInvocableHandlerMethod`
to extend the logic to newly introduced `ContinuationHandlerMethodArgumentResolver`
and call for Kotlin suspend functions.
* Remove `MessageHandlerMethodFactoryCreatingFactoryBean` since its logic now is covered with the
`IntegrationMessageHandlerMethodFactory`
* Kotlin suspend functions are essentially reactive, so use `CoroutinesUtils.invokeSuspendingFunction()`
and existing logic in the `AbstractMessageProducingHandler` to deal with `Publisher` reply
* Fix `GroovySplitterTests` for the current code base
* Add `kotlinx.coroutines.flow.Flow` support
The `Flow` is essentially a multi-value reactive `Publisher`,
so use `ReactiveAdapterRegistry` to convert any custom reactive streams result to `Flux` and `Mono`
which we already support as reply types
* Add docs for `Kotlin Coroutines`
Rearrange the doc a bit extracting Kotlin support to individual `kotlin-functions.adoc` file
* Fix missed link to `reactive-streams.adoc` from the `index-single.adoc`
* Fix unintended Javadocs formatting in the `AbstractMessageProducingHandler`
* Add suspend functions support for Messaging Gateway
* Add convenient `CoroutinesUtils` for Coroutines types and `Continuation` argument fulfilling via `Mono`
* Treat `suspend fun` in the `GatewayProxyFactoryBean` as a `Mono` return
* Convert `Mono` to the `Continuation` resuming in the end of gateway call
* Document `suspend fun` for `@MessagingGateway`
* * Make `async` implicitly only for `suspend fun`
* * Remove unused imports
* * Verify sync and async `Flow` processing
* Mention default sync behavior in the docs
* * Improve reflection in the `CoroutinesUtils`
* Fix language in docs
Co-authored-by: Gary Russell <grussell@vmware.com>
* * Rebase and revert blank lines around `include` in docs
Co-authored-by: Gary Russell <grussell@vmware.com>
The `FixedBackOffPolicy` and `ExponentialBackOffPolicy` have now overloaded
setters for `Supplier` of value.
The XML parser relies on the Java Bean specification and cannot determine
the proper setter by type.
Looks like it is just resolved by name and there is no guarantee which one
will win
* Add inner `FixedBackOffPolicy` and `ExponentialBackOffPolicy` adapters
to expose `*Simple` setters for the values we get from the XML configuration
The `#args` and `#gatewayMethod` SpEL variables have been deprecated for a while
* Remove their population and usage in favor of `MethodArgsHolder` `root` of the evaluation context
This change optimize a gateway mapping logic the way that there is no need in evaluation context
for every call: we can just reuse a global one
* Some other `GatewayMethodInboundMessageMapper` code style refactoring
* Fix effected test classes and their configs
There is just enough to check the value type name against "kotlin.Unit" literal.
This way we don't need extra reflection bits to be exposed into a native image
* Add documentation for Observability
* Adapt Observation code to the latest dependencies
* Add doc generation tasks for meters and spans
* Document new Observation API features
* Include generated meters and spans docs to a general `metrics.adoc` chapter
* * Adapt `ObservationPropagationChannelInterceptorTests` for the latest `SpansAssert` API
* * Adjust to the latest Micrometer SNAPSHOT
* Make Observation doc generation tasks only as local.
We don't need ambiguous changes to source code on CI
* * Automate metrics/spans docs generation as a part of `reference` build phase
* Replace 'org.springframework.integration' content in the generated files with a 'o.s.i'
to make it easier to read, especially in the tables
* Break `DefaultMessageReceiverObservationConvention <=> IntegrationObservation` classes tangle
using literal for `KeyValues` in the `DefaultMessageReceiverObservationConvention`
instead of nested enums from the `IntegrationObservation`
* Some other minor build script clean up
* Fix indent in `build.gradle` for `micrometerVersion` property code line
* Add new line after observation section in whats-new.adoc
* * Adapt to the latest Micrometer changes
* * Use Reactor `2022.0.0-SNAPSHOT` version
* GH-3635: Add Future<Void> & Mono<Void> to gateway
Fixes https://github.com/spring-projects/spring-integration/issues/3635
When `Future<Void>` & `Mono<Void>` is used as a messaging gateway return type,
the application hangs out on this barrier which may lead to the out of memory eventually
* Add support for the `Future<Void>` & `Mono<Void>` messaging gateway return type
and ensure an asynchronous call for the `gateway.send(Message)` operation and
its exception handling.
In case of successful call, the `Future` is fulfilled with `null` and `Mono` is completed as empty
* * Check for `void.class` as well in the `GatewayProxyFactoryBean.isVoidReturnType`
* * Allow `Future<Void>` as a reply type of the gateway request-reply operation
* * Fix Checkstyle violations
* * Resolve `System.err.println()` in the test code
* Add `Thread.currentThread.interrupt()` to the `InterruptedException` block in the test
