* Do not build exception instances in advance
When no `cause` and no clean context of the exception thrown,
the code place where an exception has been created is confusing.
* Fix `SimpleMessageStore` to create an `out of capacity` exception in the
`addMessagesToGroup()` exactly at the point where it is thrown
* Fix `FunctionExpression` and `SupplierExpression` do not pre-create `readOnlyException`:
it is unlikely these kind of expressions are going to be used in the SpEL `write` context,
so we save some time and memory not creating extra object and the plain call `throw new`
gives us a clean context what method call has ended up with such an exception
* * Extract `outOfCapacityException` to the method in the `SimpleMessageStore`
to avoid duplication.
Even if we got in the end extra line in th stack trace, it is still clear from
where it is thrown:
```
org.springframework.messaging.MessagingException: SimpleMessageStore was out of capacity (1) for group 'foo', try constructing it with a larger number.
at org.springframework.integration.store.SimpleMessageStore.outOfCapacityException(SimpleMessageStore.java:324)
at org.springframework.integration.store.SimpleMessageStore.addMessagesToGroup(SimpleMessageStore.java:302)
at org.springframework.integration.store.AbstractMessageGroupStore.addMessageToGroup(AbstractMessageGroupStore.java:189)
at org.springframework.integration.store.SimpleMessageStoreTests.shouldNotHoldMoreThanGroupCapacity(SimpleMessageStoreTests.java:128)
```
* Obtain observed timers in the Integration Graph
The `Observation` populates slightly different Micrometer timer names and their tags
* Fix `MicrometerNodeEnhancer` to search timers in the registry according to the `Observation`
convention if the provided component is observed
* For that purpose expose an `IntegrationManagement.isObserved()` option to check
of component is instrumented with an `Observation`
* Improve the logic in the `IntegrationGraphServer` to delegate into a `Function`
to call `micrometerEnhancer.enhance()` instead of `static` property which might not
be OK in the environment where several integration applications are ran in the same JVM
* * Collect times into graph for inbound gateways & producers
* Fix language in javadoc of new `IntegrationManagement.isObserved()`
* Add `@Nullable` to `MicrometerNodeEnhancer.buildTimerStats()` param to satisfy this method contract
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
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.
* 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
* 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>
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 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
* 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 `#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
* 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
* Fix new classes and packages tangles
* Move `MessagingAnnotationPostProcessor` and `MethodAnnotationPostProcessor` impls
out of the `config.annotation` package due to usage of the `FactoryBean` configs
* Move `GenericHandler` and `GenericTransformer` to the `core` package to break
a tangle with a `LambdaMessageProcessor`
* Clean up affected tests and docs
* * Fix Checkstyle violation for imports order
The `QueueChannel.receive()` may be fulfilled before
an observation is stopped in the `MessageHandler`
* Rework `IntegrationObservabilityZipkinTests` configuration to add
a `HandleMessageAdvice` to wait on the `CountDownLatch` before asserting spans
* Exclude an `adviceChain` attribute from the `ServiceActivatorAnnotationPostProcessor`
since an advice can be applied for the consumer endpoint, not the MH directly.
The `ConsumerEndpointFactoryBean` does the proper decision to apply advice onto MH
or just around its `handleMessage()` method
* Add some infrastructure for Observation
* Populate an `ObservationRegistry` bean from the `IntegrationManagementConfigurer`
into all the `IntegrationManagement` components
* Introduce `MessageReceiverContext` and `MessageSenderContext` for easier usage
in the target code
* Implement `Observation` handling in the `AbstractMessageHandler`
* Modify `ObservationPropagationChannelInterceptorTests` for new `MessageSenderContext`
* Use `BridgeHandler` to ensure that `Observation` is propagated and handled properly
* Verify that tags from the `AbstractMessageHandler` are preset on the consumer span
* * Add a `DocumentedObservation` infrastructure
* * Add `Timer` verification to the propagation test
* * Update to the latest Observation API
* * Add custom observation convention support for the `AbstractMessageHandler`
* Use more meaningful prefix for Spring Integration tags
* * Move singleton instance for `DefaultMessageReceiverObservationConvention`
into `DefaultMessageReceiverObservationConvention` per se as an `INSTANCE` constant
* Use `MeterRegistryAssert` in the `ObservationPropagationChannelInterceptorTests`
to verify meters emitted
* * And an integration test with Zipkin based on the `SampleTestRunner`
Fixes https://github.com/spring-projects/spring-integration/pull/3660
* Change the `LambdaMessageProcessor` to invoke `Function`, `GenericHandler`,
`GenericSelector` & `GenericTransformer` explicitly without reflection.
This allows to avoid `--add-opens` for Java types to be used from reflections.
Plus this removes some overhead with native images.
And in general it is faster than reflection invocation.
The `ObjectToMapTransformerTests.testObjectToSpelMapTransformerWithCycle()`
causes a `StackOverflowError` according to the parent-child-parent cycle in the model under test.
This ends up with an error in the Gradle logs:
```
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message transform method call failed at s\src\java.instrument\share\native\libinstrument\JPLISAgent.c line: 873
```
* Disable this test to avoid memory overhead and CPU time
to let Java determine stack overflow and avoid a build error
The `ObjectToMapTransformerParserTests.testObjectToSpelMapTransformerWithCycle()`
causes a `StackOverflowError` according to the parent-child-parent cycle in the model under test.
This ends up with an error in the Gradle logs:
```
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message transform method call failed at s\src\java.instrument\share\native\libinstrument\JPLISAgent.c line: 873
```
* Disable this test to avoid memory overhead and CPU time
to let Java to determine stack overflow and avoid a build error
* Rework infra logic onto IntegrationProperties
The `Properties` bean has been deprecated since `5.5`
* Register a default `integrationGlobalProperties` as a `IntegrationProperties`
* Fix respective usages from the `Properties`
* * Remove unused constant from the `IntegrationContextUtils`
* * Fix language in the `whats-new.adoc`
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
* GH-3828: Initial Spring AOT support
Fixes https://github.com/spring-projects/spring-integration/issues/3828
* Provide an infrastructure based on a new Spring AOT engine in the latest Spring Framework
* Introduce `RuntimeHintsRegistrar` impls into modules which require some reflection,
resources or proxies and serialization available in the native image
* Mark some framework method with the `@Reflective` to make their reflection
info available in the native image, for example for SpEL or JMX invocations
* Add a `GatewayProxyBeanRegistrationAotProcessor` to register proxy interfaces
info for messaging gateways (either instance of the `GatewayProxyFactoryBean`)
* Rework `ConverterRegistrar` to not use a `beanFactory.getBeansWithAnnotation()`
since it is not available after AOT phase.
Instead, register an intermediate `IntegrationConverterRegistration` bean definition
from the `IntegrationConverterInitializer`
* Refactor `GlobalChannelInterceptorInitializer` a bit according to a new logic in the
`IntegrationConverterInitializer`
* Remove `JsonNodeWrapperToJsonNodeConverter` bean registration from the
`DefaultConfiguringBeanFactoryPostProcessor` - it is added by the `ConverterRegistrar`
into the target `ConversionService`
* Fix `ParentContextTests` respectively a `JsonNodeWrapperToJsonNodeConverter` bean removal
* Refactor `XsltPayloadTransformer` to not load a `ServletContextResource`, but just use its
name for the `xslResource` condition
* * Rework AOT support according latest changes and requirements
* Remove `@Bean` reflection since it is not needed any more
* Add `AotDetector.useGeneratedArtifacts()` condition to not register beans
one more time at runtime after AOT build phase
* Fix deprecation in the WebFlux test from the latest SF
* 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
* Initial support for Micrometer Observation
* Add respective Observation dependencies
* Refactor an `AbstractMessageHandler` logic for potential Observation hooks
* Introduce an `ObservationPropagationChannelInterceptor` to propagate
an `Observation` from one thread to another through message channels
* Adds an example of propagation
* Fixed the user code and receiving spans
* * Clean up for Tracing unit test
* Make `micrometer-observation` as an `api` dep - non-optional for direct API usage
Co-authored-by: Marcin Grzejszczak <marcin@grzejszczak.pl>
