Fixes https://github.com/spring-projects/spring-integration/issues/3936
I am passing request attributes which is getting used in exchangefilter to influence the flow. This request attribute is of type String as Key and Value as a user defined object.
My expectation is to pass this information in request attributes so that it will eventually available in exchangefilter for further processing but i dont find a way to pass these request attribute in webflux integration.
* Add webclient request attributes into `WebFluxRequestExecutingMessageHandler`
* Improve code style and docs
* 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
Resolves https://github.com/spring-projects/spring-integration/issues/3942
When determining the default reply-to topic/partition, we need to wait for assignment.
Already covered by `KafkaDslTests` (a recent build failure exposed this problem).
**No back-port - 5.5.x uses 2.7.x by default, which does not support this.**
5.5.x users can call `waitForAssignment` on the `ReplyingKafkaTemplate` that is
supplied to the gateways before sending messages.
The default expression in the `DefaultFileNameGenerator`
is based on a message header which simply can be retrieved
with much faster `FunctionExpression`
* Some other code style refactoring in the `DefaultFileNameGenerator`
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
It looks like some of Spring project's bom added after `spring-framework-bom`
causes a mess with dependencies: it brings those SF deps which are in the
latest `mavenBom`
* Move `spring-framework-bom` to the end of the list to be sure that
its version comes properly
* Do the same for Spring Data - after Spring AMQP and Spring Kafka
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
* Copy docs to the `$buildDir/reference` instead of `docs`
to make `asciidoctor` tasks to calculate their UP-TO-DATE key properly
* Generate `kdoc` outside the `docs` dir to not interfere with `asciidoctor`
* Downgrade Tomcat to `10.0.23` since SF-6.0.0-RC3 is not compatible yet
* Exclude `jakarta.activation` and `com.sun.mail` transitive deps to avoid
classpath conflict with Jakarta EE 10
* Fix mail module to fit to the latest mail API requirements
* Fix the last Sonar smell in the `SmbShare`
* Remove redundant dependency for `hamcrest-core` in various modules
* GH-3938: Fix HTTP XML configuration for ambiguity
Fixes https://github.com/spring-projects/spring-integration/issues/3938
The `encoding-mode` is a property of the `RestTemplate`.
Therefore, it cannot be set on the component configuration together with
an externally injected `rest-template`
Even if `HttpRequestExecutingMessageHandler` has an assertion for such
an ambiguity, the XML parser just ignores this `encoding-mode`
when it encounters the `rest-template`
* Fix `HttpAdapterParsingUtils.verifyNoRestTemplateAttributes()` to check for not allowed
attributes with a `encoding-mode` as well
* Remove a `default` from the `encoding-mode` to not cause an ambiguity in the parser
* Fix some typos in the `spring-integration-http.xsd`
* Rework `OutboundResponseTypeTests` to JUnit 5
**Cherry-pick to `5.5.x`**
* * Fix error handling for `encoding-mode` in the `HttpAdapterParsingUtils`
* Cover `encoding-mode` and `rest-template` ambiguity with a test against failing XML configuration
* * Improve error message for ambiguous attributes in the `HttpAdapterParsingUtils`
* 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
* Add Java DSL for Camel module and docs
* Introduce a `LambdaRouteBuilder` option into the `CamelMessageHandler`
to easily provide the Camel route just in-place
* * Fix language in docs
Co-authored-by: Gary Russell <grussell@vmware.com>
Co-authored-by: Gary Russell <grussell@vmware.com>
